The OWASP Agentic Top 10 Is an Identity Problem in Disguise

OWASP published the Agentic Top 10 and the security community responded predictably: ten new problems, ten new solutions, ten new vendors.

Except they're not ten problems. They're three.

Identity. Authority. Evidence.

Get those right and you've neutralized 70% of the list before you write a single line of agent code.

The Pattern Nobody's Talking About

Look at the OWASP Agentic Top 10 through a different lens. Don't ask "what's the threat?" Ask "why does this attack work?"

• ASI03: Identity & Privilege Mismanagement → No per-agent identity
• ASI04: Supply Chain Tampering → Unsigned descriptors, no provenance
• ASI05: Multi-Agent Authorization Gaps → No delegation chains
• ASI07: Insecure Inter-Agent Communication → No caller verification
• ASI10: Rogue/Compromised Agents → No revocation, no containment
• ASI06: Misaligned Agent Goals → Weak authority bounds
• ASI09: Excessive Autonomy → Overbroad permissions

Seven of ten. All rooted in identity, authority, or the evidence to prove both.

The remaining three—prompt injection, data exposure, unsafe tool usage—are real, but they're symptoms made worse by the identity gap. When you can't tell which agent did what, under whose authority, you can't contain the blast radius. You can't revoke. You can't investigate.

Identity isn't the whole solution. It's the foundation that makes everything else possible.

The Three Controls That Actually Matter

1. Identity: Know Who's Talking

Every agent needs a unique, verifiable identity. Not a shared service account. Not an API key copied across twelve agents. A cryptographic identity that can be verified by anyone who needs to trust that agent.

This is what DIDs were built for. A did:key in development, a did:web in production. The agent owns a keypair. The identifier proves ownership. No phone-home to a central service required.

Without per-agent identity:

• Your logs say "an agent called the refund API"
• You can't revoke one agent without breaking all of them
• You can't tell if a request came from your agent or an impersonator

With per-agent identity:

• Your logs say "did:web:api.acme.com:agents:support-bot called the refund API at 14:32 UTC"
• You can revoke one agent in seconds
• You can verify the caller cryptographically

Quick test: Can two different agents be distinguished in your logs without guessing?

2. Authority: Know What They Can Do

Identity answers who. Authority answers what they're allowed to do.

The failure mode is familiar: you give an agent broad permissions because scoping is hard, then something goes wrong and you realize the agent could access everything.

The fix is short-lived, scoped credentials:

• Short TTL: 5 minutes, not 90 days. A stolen credential becomes useless fast.
• Audience scoping: This credential only works for the refund service, not the entire API.
• Action scoping: Read and create refunds. Nothing else.
• Environment scoping: Staging credentials don't work in production.

When agents delegate to other agents, authority should only decrease. The receiving agent can never have more permissions than the delegating agent. This is the "Golden Rule" that prevents privilege escalation in multi-agent systems.

Quick test: If an agent's credentials leak, how long until they're useless? If the answer is "until we rotate them," you have a problem.

3. Evidence: Know What Happened

When something breaks—and something always breaks—you need to reconstruct the chain of events.

Audit isn't compliance theater. It's your investigation toolkit.

Every agent action should be logged with:

• Agent identity (DID or unique ID)
• Credential ID that authorized the action
• Policy that allowed or denied it
• Action taken, target resource, outcome
• Timestamp and correlation ID

If your audit trail can answer "who did what, under whose authority, when?" you can investigate incidents in minutes instead of days.

Quick test: An agent makes an unexpected API call at 3am. Can you determine which agent, which credential, and which policy allowed it—within 15 minutes?

The OWASP Risks, Mapped

Here's how the identity/authority/evidence triad addresses each risk:

ASI03: Identity & Privilege Mismanagement

• Translation: "Agents share credentials and have overbroad permissions"
• Fix: Per-agent identity + scoped, short-lived credentials
• Quick test: Can you disable one agent without affecting others?

ASI04: Supply Chain Tampering

• Translation: "Agent cards and tool manifests can be modified without detection"
• Fix: Sign descriptors, verify signatures, track provenance
• Quick test: Would you detect if someone modified your agent's tool manifest?

ASI05: Multi-Agent Authorization Gaps

• Translation: "Agent A delegates to Agent B with no audit trail or authority bounds"
• Fix: Explicit delegation chains, authority can only decrease
• Quick test: Can Agent B escalate privileges beyond what Agent A granted?

ASI07: Insecure Inter-Agent Communication

• Translation: "Any caller can hit agent endpoints; trust is based on IP, not identity"
• Fix: Require credentials on inter-agent calls, verify caller identity
• Quick test: Can an unregistered agent call your agent and succeed?

ASI10: Rogue/Compromised Agents

• Translation: "You can't stop a bad agent without taking down everything"
• Fix: Credential revocation + agent-level disable + audit for forensics
• Quick test: Can you stop a compromised agent in under 5 minutes?

ASI06 & ASI09: Misaligned Goals / Excessive Autonomy

• Translation: "Agents do things they shouldn't because nothing stops them"
• Fix: Authority bounds, enforcement at the boundary (not inside the prompt), human-in-the-loop for high-risk actions
• Quick test: Does your agent have access to resources it has never needed to use?

What Identity Doesn't Solve

To be clear: identity, authority, and audit don't fix everything.

Prompt injection is a model-level problem. Identity limits the blast radius (a compromised agent can only do what its credentials allow), but it doesn't prevent the injection itself.

Sensitive data exposure requires data classification and egress controls. Identity tells you who leaked data; it doesn't prevent the leak.

Unsafe tool usage needs sandboxing and human approval gates. Identity ensures you know which agent tried to use the tool.

Identity is foundation, not finish line. But without the foundation, the other controls can't work. You can't sandbox an agent you can't identify. You can't rate-limit an agent that shares credentials with twenty others. You can't revoke access for an agent that has the same permissions as your entire fleet.

The Path Forward

You can build this yourself:

This week: Give each agent a unique identifier. Even a UUID is better than shared service accounts.

Next week: Add a gateway or middleware that verifies credentials before forwarding requests. No credential = no access.

Week after: Implement short TTLs and scoping. Add audit logging with agent identity.

Month after: Add revocation. Connect audit to alerting.

Or skip the infrastructure work.

CapiscIO handles identity issuance, credential lifecycle, revocation, and audit out of the box. One line to connect your agent, and you get Trust Badges with built-in TTL, scoping, and a revocation API that propagates in seconds.

capiscio init --name "my-agent"

That's the whole setup. The controls described in this post—identity, authority, evidence—are what CapiscIO implements under the hood.

Build it yourself if you want to understand every layer. Use CapiscIO if you want to ship this week.

The Diagnosis

You don't need to solve all ten OWASP risks at once. Solve the three that underpin them.

The OWASP Agentic Top 10 looks like a taxonomy. It's actually a symptom list. The diagnosis is simpler: your agents don't have identity, their authority isn't bounded, and you can't prove what happened.

Fix that, and you've fixed most of it.