The biggest security risk may not be the code your team writes. It may be the code and services your team trusts with credentials, data, and update authority, and AI adoption has added many of them: gateways, model providers, connectors, and tool servers. Each one ships updates, and checking every release by hand does not keep pace.
An AI agent can do that checking continuously. It maps what you depend on, compares every new release with its expected source and build, works out what each component could reach if compromised, and stops a release that does not match before it reaches production. Your component owners make the trust decisions the agent cannot.
All component names, identifiers, versions, times, and findings in this guide are fictional. Credential references contain no secret values.
Let the agent map what the workflow trusts
Point the agent at your package manifests, image registries, deployment configuration, and supplier records. It lists packages, images, gateways, connectors, agent skills, tool servers, hosted services, and model providers. For each one, it records who can see data, hold credentials, publish updates, or change behavior remotely. It includes suppliers that store your secrets, even when none of their software runs on your servers.
Each component needs a business owner. The agent proposes one from commit history, deployment records, and billing, and asks the likely owner to confirm. The security review checklist covers wider agent intake; this guide covers the dependencies around it.
Let the agent trace each release to the artifact you run
For every update, the agent follows the chain from source repository to build, publisher, downloaded artifact, and deployment. It records the approved source, publisher, version, and deployed digest. Tags can point to different bytes over time, so the agent pins its comparison to digests. Inspecting source and identifying the deployed artifact answer different questions, and the agent records both.
The check runs before production access is granted, so a mismatched release stops at the hold point.
Check provenance and understand its limits
Where your tools support it, the agent verifies signatures and build attestations against approved identities and compares artifact fingerprints. It pins deployments to digests rather than tags that can move.
A matching fingerprint identifies bytes. It does not prove they were built from approved source, and a valid signature can still come from a compromised upstream process. That is why the agent checks the signer, source, and build evidence together. Missing provenance is recorded as an open gap, never as a pass.
Let the agent map what each component can access
For each component, the agent records credential identifiers, readable data, permitted actions, connected accounts, and reachable systems. It answers the question an attacker would ask: what could this component read, change, send, or unlock if compromised? It then drafts how to narrow or revoke each grant, and how long that would take.
A gateway may hold provider keys and read request traffic. A connector may write business records. Broad access can make a familiar component a higher priority even when its provenance checks pass. Use tool and data access review and permissions and boundaries for per-operation checks. LLM gateway vs. AI agent platform separates routing and credential scope from agent execution.
Hold the unexpected change, then investigate it
Candidate gateway 2.8.0 arrives at 11:02. Its fingerprint matches the published release, but its release record names gateway-releases-mirror instead of the approved source gateway-releases.
The deployment pipeline promotes a release only after the agent's verification check passes, so the agent's failed check holds run pipe-7731 at 11:04. Production stays on 2.7.4. The agent cannot promote a release or override the rule; it can only decline to sign off.
The agent then investigates the hold:
- The mirror's build attestation names a builder identity that is not on the approved list.
- The approved source has no 2.8.0 release yet.
- The candidate requests one new permission, outbound access to an unlisted host.
It quarantines the candidate and sends the platform owner one finding with the evidence attached. The owner has a single question to answer: is the mirror a legitimate source? The agent has already worked out why the release should not run until that answer comes.
The agent also proposes the other hold conditions from your release history, and once the owner approves them it applies them the same way every time: an unexpected publisher, a missing or different signer, a mismatched digest, or new permissions.
Trust worksheet: gateway release review (illustrative)
- Provenance: Component
gw-prod, routing internal-agent model requests. Owner: platform team. Approved sourcegateway-releases; publisher recorded in release policy. Candidate 2.8.0, digestsha256:9f2c…41aa, received 11:02. Deployed 2.7.4, digestsha256:51b0…07d3, unchanged at 11:06. Fingerprint matches; source is an unapproved mirror; builder identity unrecognized; no matching release at the approved source. Digests abbreviated for display.- Access: Credential references
cred-gw-p1,cred-gw-p2,cred-gw-p3. Reads request traffic and holds provider keys; no business-record writes. Candidate adds outbound access to an unlisted host. Consequence of compromise: credential exposure and request interception.- What the agent did: Failed its verification check, which held
pipe-7731at 11:04. Quarantined the candidate, investigated the mirror, and sent the owner one finding with evidence.- Decision for the owner: Whether
gateway-releases-mirroris a legitimate source. Until then the candidate stays quarantined.
Trust worksheet: hosted supplier access (illustrative)
- Provenance: Contracted host
host-sup-a, runningapp-internal-01andapp-internal-02. Owner: platform team. The supplier manages deployment. The agent checked exported configurationcfg-118on 2026-10-20 and reviewed 90 days of supplier change notices; none reported secret-storage changes. These records do not independently verify the supplier's build process.- Access: References
secret-app01-db,secret-app01-api,secret-app02-api. The supplier stores the secrets and injects them at runtime. Reach: the database and provider accounts those secrets unlock.- What the agent did: Mapped all three secrets to their issuers and consumers. Rehearsed issuer-side replacement for
secret-app02-apiin staging; replacement took 12 minutes end to end.- Decision for the owner: None now. High priority because of reach; the agent repeats the review when the supplier sends its next change notice.
The agent keeps one worksheet in this format per component. Use the blank version to set what you expect it to report:
Software and supplier trust worksheet (blank)
- Provenance: Component ___ · Business use ___ · Owner ___ · Approved source and publisher ___ · Candidate version and digest ___ · Deployed version and digest, checked at ___ · Signature, attestation, and fingerprint evidence ___
- Access: Credential IDs ___ · Data and action scope ___ · Reachable systems ___ · Consequence of compromise ___ · How to narrow or revoke ___
- What the agent did: Checks run ___ · Discrepancies found ___ · Holds and their enforcing system ___ · Investigation results ___
- Decision for the owner: Question ___ · Priority and rationale ___ · Still unverified ___ · Status ___
Prepare for compromise and recovery
For important components, the agent keeps the response owner, dependent consumers, and source of current remediation guidance on file. If a supplier announces a compromise, the agent preserves artifact identity and logs, holds further rollout, and pulls the specific advisory. It then works each exposed credential through issuer-side containment and consumer recovery. Removing a package alone does not establish recovery, because persistent changes may need further cleanup or a rebuild.
Start with one gateway or connector and have the agent map it from source and supplier through artifact and access. Defensive AI agents shows how to set up update checking as a testable job.
In AgentShelf
Configure an agent to collect release evidence, investigate discrepancies, and report to the component owner. Your deployment systems must enforce the hold. See trust boundaries, or request agents to discuss a supplier-review workflow.