Agent identity and your vulnerability and supply chain program

Agent identity tells you which AI agents exist and what each can reach. Vulnerability management and software supply chain security tell you which components are weak. Together they answer the practical question: if this component or credential is compromised, which agents, and which systems behind them, are affected?

Why connect them at all?

Because agents are software with credentials. They run on frameworks, call plugins and tool servers, and use tokens. A flaw in a plugin is a vulnerability question. A token held by an agent is an identity question. The consequence depends on both.

OWASP's guidance on Excessive Agency says agent harm usually has one or more root causes: excessive functionality, excessive permissions or excessive autonomy. Vulnerability data tells you where something might break. Identity data tells you what it could do when it does.

What does each side give the other?

Identity gives vulnerability management a blast radius. A flaw in a library used by an agent with read only access to docs is a lower priority than the same flaw in an agent that can deploy to production. Without identity data, both look the same.

Vulnerability and supply chain data gives identity a risk signal. An agent running a component with a known exploited flaw is a higher risk, whatever its permissions say on paper. CISA's Known Exploited Vulnerabilities catalog lists flaws with evidence of exploitation, which is a clear flag.

Supply chain data gives identity an inventory source. Repositories, pipelines and package manifests show where agents are defined and what they depend on. That finds agents nobody registered.

What are the main joins?

1. Agent to component. For each agent: the framework, plugins, tool servers and libraries it uses.
2. Agent to credential. For each agent: the tokens and keys it holds, their scope and their expiry. OWASP's Non-Human Identities Top 10 lists long lived secrets, overprivileged identities and reuse of one identity across systems among key risks.
3. Agent to owner. The person or team who answers for it.
4. Agent to environment. Which systems and data it can reach, in which environment.

With these four joins, a new advisory becomes a query: which agents run this component, what do they hold, who owns them?

A constructed example

This is made up. A tool server library used for file access gets a critical advisory with evidence of exploitation. The security team queries the joined records. Seven agents use the library. Five have read only access to a documentation store. Two can write to a customer support system. The two get patched first, their tokens are rotated, and the owners are told. The other five follow in the normal cycle. Without the joins, the team would have patched all seven in arrival order and not known which two mattered.

Where does it break?

• Agents defined outside repositories, for example in a SaaS builder, never appear in code scans.
• Credentials are stored in a vault with no link to the agent that uses them.
• Reachability is unknown: the library is present, but is the vulnerable function used?
• Owners leave and the record goes stale.

Who should own the joined view?

Pick one team to keep the records, usually platform or security engineering, and make every agent owner responsible for their own entries. Shared ownership of the whole list tends to mean no ownership. A quarterly review, with a short list of agents that changed hands or went quiet, keeps the data honest.

What to do

1. Add agents to your asset inventory with the four joins above.
2. Pull agents from three sources: repositories, platform admin pages and credential stores. Compare the lists.
3. Add blast radius to your ranking: what the agent can write or delete.
4. Add known exploited flaws as an automatic priority flag.
5. Check reachability before you declare an agent affected.
6. Review owners each quarter and reassign orphaned agents.

Where Safeguard fits

Safeguard's agent identity capability tracks which agents hold what access at what level, and its reachability analysis checks whether a vulnerable dependency is actually used. Used together, they support the join described here: a flaw in a component, mapped to the agents and access behind it. Policies and guardrails can then enforce limits at build, CI and release. Safeguard covers the application and delivery side, not workforce identity.

Quick check

Sources

• OWASP LLM Top 10, Excessive Agency
• OWASP Non-Human Identities Top 10
• CISA Known Exploited Vulnerabilities catalog

Last reviewed: 18 October 2026.