A forgotten system can keep serving customers and holding working credentials long after its repository was archived. Finding these systems used to mean weeks of manual cross-checking, and that is exactly the work an AI agent does well. It reconciles repository, deployment, dependency, and access records, works out which systems matter, prepares the patch or migration, and retires what is no longer needed. Your team decides how far each repair should go.
All asset names, identifiers, dates, and findings in this guide are fictional.
Connect the repository to the running system
No single record tells the whole story:
- A repository shows source and maintenance history.
- A deployment shows what actually runs.
- A scheduled job shows work that happens with nobody watching.
- A credential grants access that can outlive all three.
Archiving source does not stop a deployment or revoke a credential.
The agent links these records for each system. A system only counts as retired when the deployment, scheduler, and credential issuer all confirm it. Anything the agent cannot match stays on the list with an owner and a next step.
An archived repository can still have a live deployment and live access behind it. The agent follows all three to one decision.
Let the agent assemble the inventory
Give the agent read access to repository metadata, deployments and scheduled jobs, dependency manifests, and credential metadata, and ask it for the inventory. It builds and maintains the list itself. It dates each fact, records its source, and keeps unmatched deployments and unknown owners visible instead of dropping them.
Keep secret values out of the agent's inputs and records entirely. It works from credential identifiers, owners, and dates, and it confirms effective permissions with the issuing service or IAM policy, because a secret manager's description can be incomplete. See review an agent's tools and data access.
The agent treats source comments, dependencies, and retrieved files as untrusted input. It analyzes code without running it where possible. When a check must run code, it does so in an isolated environment under a scoped identity.
Let the agent find the exposure that needs attention
The agent looks for dangerous combinations: a vulnerable service that accepts internet traffic, sensitive data that its process can reach, or credentials that open other systems. It treats each proposed attack path as a hypothesis and then tests it:
- Does the deployed version match the advisory?
- Is the vulnerable code reachable?
- What do the credentials actually permit?
An unsupported runtime alone does not prove an exploit, and a clean scan covers only what the scanner reached and recognized. The agent records both limits.
Rank what to patch, replace, or retire
The agent ranks systems by business use, reachability, sensitive access, dependencies, and consequences, and proposes one of three outcomes:
- Patch a needed system that has a supported fix.
- Replace one that cannot be maintained safely.
- Retire one whose business need has ended.
Compare a public customer portal with an archived internal prototype. Both repositories have been quiet for over a year, but the portal still serves customers and exports data every night. The agent puts it first and does the investigation the owner would otherwise have to do.
Exposure and disposition record:
portal-prod-03(illustrative)
- Identity: Repository
portal-web, archived 2024-06, last commit 2024-05. Deployment active and internet facing, last deployed 2025-11. Business use: customer logins and account pages. Jobnightly-exportruns daily at 01:30 to a reporting store.- What the agent confirmed (2026-10-20):
- Public login is reachable.
- The runtime is a version line outside regular support. The vendor's last fix for that line does not cover advisory
ADV-PRT-22, which affects the deployed version.- In staging, the vulnerable route is reachable without signing in.
- Issuer records show
cred-portal-app-01can read the customer table.cred-export-02writes to the reporting store, and one consumer,bi-dash, reads that store.- The previous owner left in 2025-03.
- What the agent prepared:
- A migration branch moving the portal to a supported runtime, with dependency updates and passing tests in staging.
- A temporary rule that blocks the vulnerable route at the edge.
- A migration plan for
nightly-exportthat keepsbi-dashworking.- Decision for the owner: Approve the edge rule now, then choose between replacing the portal on the prepared branch or retiring it with the business owner. Interim owner: platform lead, proposed by the agent from deployment history and confirmed 2026-10-20. Status: open, decision prepared.
Exposure and disposition record:
prototype-07(illustrative)
- Identity: Repository archived; business use ended, confirmed with the product owner on 2026-10-19.
- What the agent confirmed (2026-10-20): Deployment check
DEP-707and scheduler checkJOB-707find no active deployments or jobs in the reviewed accounts. No consumer has read credentialcred-proto-07in 90 days.- What the agent did: The credential meets every condition of the pre-approved retirement policy, so the agent revokes it at the issuer and retrieves receipt
REV-707(2026-10-20). It then links that receipt in the secret catalog and archives the asset record.- Result: Retirement verified for the reviewed accounts through deployment, job, and issuer evidence. No action needed from a person.
The agent keeps one record in this format for every system it finds. Use the blank version to set what you expect it to report:
Exposure and disposition record (blank)
- Identity: Asset ___ · Repository status and last activity ___ · Deployment status and last deploy ___ · Runtime and dependencies ___ · Scheduled jobs ___ · Business use ___
- What the agent confirmed: Reachability ___ · Credential IDs (never values) ___ · Issuer or IAM permissions ___ · Tested attack path ___ · Remaining uncertainty ___ · Sources and dates ___
- What the agent prepared or did: Patch, migration, or temporary control ___ · Actions taken under policy ___ · Evidence ___
- Decision for the owner: Patch, replace, or retire ___ · Owner ___ · Reviewed scope ___ · Status ___
Let the agent carry out the chosen work
AI makes the repair itself cheaper. The agent can explain unfamiliar code, map dependencies, draft the patch or migration, write tests, and run them in staging. It applies that effort to the top of the ranked list, not to whatever is easiest to fix.
Decide in advance which changes the agent makes on its own; the agent can draft that policy from the ranked list, but a person approves it. The issuer and deployment systems enforce it. In the example, the agent's identity can revoke a credential only when it is tagged for retirement and has no recent consumers. That is why the agent could retire prototype-07 on its own, while cred-export-02 waits on the bi-dash migration and an owner's decision. If a credential may already be compromised, contain it now under your incident policy rather than waiting for the cleanup.
Changes to the agent itself follow agent change management.
Close the exposure with evidence
After each change, the agent rechecks the deployed result and its effect on the exposure. For a retirement, it keeps the deployment, scheduler, and issuer-side evidence together. Deleting a secret-manager entry does not prove revocation, so the agent asks the issuer. Missing ownership or unknown dependencies stay open, with the agent following up until someone answers.
Point the agent at one application and have it reconcile that system's records end to end. Start with defensive AI agents if no job brief exists yet, and use the governance checklist for program ownership and review dates.
In AgentShelf
Configure an agent to assemble approved records, prepare repairs, and track unresolved items. Production repairs and retirements still need testing and the authority your systems enforce. See governance and cost controls, or request agents to discuss cleanup.