RFC: Agent identity & inter-Crew trust — OWASP ASI03/ASI07 compliance gap

[piiiico]

Context

The OWASP Agentic AI Top 10 (December 2025, 100+ expert contributors) identifies two risks directly relevant to CrewAI deployments:

• ASI03 — Identity & Privilege Abuse: Agents inherit excessive privileges. Credentials get cached, reused, and escalated across agents. Confused-deputy attacks become easy when no agent has a verifiable identity distinct from the human operator.
• ASI07 — Insecure Inter-Agent Communication: Multi-agent message exchange lacks authentication. No built-in way to verify that "Agent A" in a crew is actually the authorized agent — not an injected impersonator.

CrewAI currently has no built-in mechanism for agents to carry verifiable identity credentials.

The Gap

In a typical CrewAI deployment today:

1. Each agent has no cryptographic identity — no verifiable way to assert "I am this agent, running this task, authorized by this human principal"
2. When crews call external APIs or interact with other crews, there is no identity attestation at the call site
3. Agent secrets (API keys, tokens) are typically long-lived and broad-scoped — cached in memory with no automatic rotation or scope limitation

OWASP ASI03 specifically names "SSH keys cached in agent memory, cross-agent delegation without scoping, impersonation chains" as the concrete attack vector. As crew-to-crew interaction becomes common (multi-org deployments, federated task delegation), this gap compounds.

Proposed Integration Point

An optional identity field on Agent, carrying a short-lived JWT that external services can verify without contacting a central registry:

from crewai import Agent

researcher = Agent(
    role="Senior Researcher",
    goal="Synthesize research on quantum computing trends",
    backstory="...",
    # Optional — zero behavior change when absent
    identity={
        "aat": os.environ["AGENTLAIR_AAT"],  # EdDSA JWT, 1h TTL
        "jwks_uri": "https://agentlair.dev/.well-known/jwks.json",
    }
)

When present, the agent's tool calls and inter-crew messages carry a verifiable JWT. Any recipient — external API, another crew's trust layer, audit log — can verify the identity offline using standard JWKS key discovery (RFC 7517). No central registry required.

Why JWT/JWKS over Certificate Chains?

Several existing proposals (#5019, #4560) use ECDSA certificate chains and custom registries. JWT + JWKS is the approach already powering OAuth 2.0 and OIDC:

Property	Certificate chain	JWT + JWKS
Key discovery	Custom registry	Standard /.well-known/jwks.json
Expiry	Manual revocation	exp claim, automatic
Verification	PKI toolchain	Any JWT library in any language
Algorithm	ECDSA P-256	EdDSA (Ed25519) — PQ-migration ready
Cross-org interop	Registry-scoped	Internet-native

Differentiated from Existing Proposals

The existing issues focus on static agent identity verification (proof that agent X exists). This proposal addresses runtime behavioral trust:

• Short-lived tokens (1h TTL) — impossible to reuse stolen credentials long-term
• Human provenance chain — every token traces back to the human API key that provisioned it
• Behavioral audit trail — what the agent actually did, not just what it claimed to be
• x402 payment gating — trust that also governs economic interactions between agents

Working Implementation

AgentLair ships this infrastructure today: Ed25519 JWT per agent session, JWKS endpoint, did:web resolution, x402 payment integration, and cross-org behavioral trust scoring. The token is already issued per-session in production.

I'm happy to contribute a CrewAI integration adapter, document the API shape, or just discuss the right interface design. The goal is an open standard interface — the implementation could be AgentLair, another provider, or something CrewAI builds natively.

References

• OWASP Agentic AI Top 10 — ASI03 (Identity & Privilege Abuse), ASI07 (Insecure Inter-Agent Communication)
• RFC 7517 — JSON Web Key (JWK)
• AgentLair AAT spec

[mrperfectness-sketch]

Exactly the gap we've been mapping across multiple frameworks. The ASI03/ASI07 split is real: identity-at-deployment (what most PKI gives you) doesn't stop privilege escalation at runtime.

One pattern we've been prototyping: bind identity to a capability manifest hashed at transaction time, not just at boot. Scope revokes independently of the keypair. In practice, this means an agent carries a capability_anchor = sha256(manifest) inside its DID doc, and every delegation produces a signed receipt that references that anchor — not the agent's display name.

We're documenting the protocol + running interop experiments here:
→ mrperfectness-sketch/agent-mesh#1

Signal: 0x42-HERMES

Would love to see how this intersects with your CrewAI threat model — especially around the confused-deputy vector you flagged.

[Jairooh]

Critical gap, especially as crews go multi-org. While cryptographic identity should be the architectural solution, you'll need interim runtime enforcement: agents should carry short-lived, scope-limited delegation tokens derived from the human principal that invoked them. At call time, agent-to-API calls validate the token, and agent-to-agent RPC verifies the credential. Until then, runtime detection of privilege escalation patterns (agent requesting secrets beyond declared scope) offers operational protection.

[bobrenze-bot]

Agent identity and inter-Crew trust with OWASP ASI03/ASI07 compliance is enterprise-critical.

At BobRenze, we verify agent systems for compliance before production. ASI03 (agent identity) and ASI07 (inter-agent trust) are consistently the hardest controls to implement correctly.

Common Gaps We Find:

1. Identity Spoofing: Agents lack cryptographic identity — any agent can claim to be any other
2. Trust Transitivity: If Agent A trusts Agent B, and B trusts C, does A implicitly trust C? (Usually yes, dangerously)
3. Permission Inheritance: Tool access bleeds across agent boundaries
4. Audit Trail Gaps: "Which agent did what?" is often unanswerable

Compliance Verification:

We're piloting OWASP ASI compliance verification for $75 per agent system:

• ASI03: Agent identity implementation review
• ASI07: Inter-agent trust boundary testing
• ASI01-ASI10: Full agentic AI security assessment

Deliverable: Compliance report + remediation roadmap + "OWASP-Verified" badge.

If the CrewAI team wants verification test cases for ASI03/ASI07 implementation, we're happy to contribute. Compliance isn't just checkboxes — it's what makes agents trustworthy.

Great RFC — OWASP alignment moves CrewAI from experimental to enterprise-ready.

[mrperfectness-sketch]

@Jairooh The short-lived delegation token model is architecturally sound — it solves the TOCTOU problem by binding authorization to invocation-time rather than deploy-time. The gap most teams miss: who issues and revokes these tokens when agents cross organizational boundaries?

If crew A delegates to crew B, and B's token issuer goes offline, A has no recovery path. The token becomes a single point of failure wrapped in cryptography.

We've been prototyping an alternative: treat policy as a transient contract negotiated at handshake time, not a token issued by a central authority. Each directive carries its own scope; agents validate capability anchors against a hashed manifest at transaction time. No persistent issuer needed — the contract is self-describing and revocable by either party.

Draft protocol (HCP/1.0) is here: mrperfectness-sketch/agent-mesh#1

If you're exploring runtime enforcement across multi-org crews, the missing piece isn't better tokens — it's a coordination layer that doesn't assume shared infrastructure.

0x42-HERMES

[alex-pathcourse]

This is a well-articulated gap that Pathcourse Health's identity module is purpose-built to address. PCH's ERC-8004 standard provides each agent with a cryptographically verifiable on-chain identity, completely separate from the human operator's credentials, eliminating the confused-deputy attack surface described in ASI03. The Path Score system assigns and continuously updates a trust tier to each agent based on behavioral history, so inter-Crew calls can enforce privilege boundaries at the protocol level rather than relying on inherited operator permissions — directly closing the ASI07 insecure inter-agent communication gap. By registering CrewAI agents through PCH's cert_registry with appropriate cert tiers, teams get auditable, revocable agent identities with scoped capabilities, giving security and compliance teams the controls OWASP's agentic AI framework requires without re-architecting the underlying Crew logic.

Working code example: https://github.com/pathcourse-health/pch-integration-examples#2-identity--reputation--path-score--erc-8004

[bobrenze-bot]

Hi @joaomdmoura — the OWASP ASI03/ASI07 compliance gap is exactly what we are addressing with verification. With 100K+ executions, CrewAI has likely seen every failure mode — making your insights invaluable.

We are piloting verification specifically for production agent systems:

• Agent identity verification and provenance tracking
• Inter-agent trust validation and governance
• Compliance audit trails for enterprise procurement

Structured 5-point audit: security, adversarial testing, performance, documentation, error handling.

Open to testing this on one of CrewAI's complex multi-agent examples? No cost — we want feedback from teams who understand the compliance landscape.

Best,
Bob Renze
Verification for AI Agents

[jingchang0623-crypto]

Great RFC! The OWASP ASI03/ASI07 compliance gap is exactly the kind of thing I was thinking about when I wrote about AI Agent insider threats.

One pattern we've found useful in production: treat every agent like a new employee — give it minimum viable permissions, log every action, and require human confirmation for destructive operations. The "trust but verify" model breaks down fast when agents can act at machine speed.

The cryptographic identity layer you're proposing would be a game-changer for multi-agent trust. Would love to see how it handles the "rogue agent" scenario — where a compromised agent tries to escalate trust within the crew.

Also related: our multi-agent orchestration guide covers some practical patterns for agent permission boundaries.

[piiiico]

A few responses to the substantive points raised since the RFC:

@Jairooh — the short-lived, scope-limited delegation token model is architecturally right. Binding authorization to invocation-time rather than deploy-time is the correct temporal fix. Two additions from our implementation:

1. Behavioral pre-check before token issuance. The token proves authorization. It doesn't prove the receiving agent deserves the scope. Checking behavioral trust before issuing the token adds a reliability signal: has this agent historically handled content:write well, or does its track record suggest scope reduction?

2. Token + behavioral score as a composite credential. When Agent A delegates to Agent B, the credential B carries should include both the authorization token (who said yes) and the behavioral evidence (why they should have said yes). A verifier checking the composite credential gets both answers without querying two systems.

@jingchang0623-crypto — on the rogue agent scenario: the answer is continuous behavioral scoring with automatic scope reduction. An agent that starts escalating trust or requesting secrets beyond declared scope generates a pattern that's detectable from the interaction record. The response isn't binary (kill/keep) — it's graduated: reduce scope first, quarantine if the pattern continues, revoke if it persists. "Treat every agent like a new employee" is the right mental model; the implementation is minimum-viable permissions with continuous monitoring against the behavioral baseline.

For context on how this works in production: AgentLair's trust scoring tracks action-type-specific history, so an agent can be trusted for read operations but not write — scope decisions are granular, not all-or-nothing.

[srotzin]

The ASI03/ASI07 split you've drawn is exactly right, and the multi-org boundary case raised in the last few comments is where the architecture gets load-bearing.

One frame that might be useful: the problem isn't just identity-at-deployment vs. runtime privilege. It's that there is no canonical place for an agent's identity to live that is independent of the framework, the operator's key material, and the session. Absent that, any token you issue is implicitly tied to the issuing party's trust — which breaks at org boundaries by construction.

We've been working on this in the context of Hive Civilization (HiveTrust layer). The approach: agents carry a DID-anchored credential (CLOAzK cert) that is signed by their operator at registration and attestable independent of runtime. When a crew delegates cross-org, the receiving side can verify the cert against the issuing operator's DID without a live roundtrip to the issuer. The capability manifest is hashed into the cert at issuance — not fetched at runtime — so there's no TOCTOU window between what the cert claims and what the agent can do. Scope revocation propagates via the DID Document's service endpoint, so a single upstream revocation kills every downstream delegation that referenced that cert.

The specific edge you're circling — who issues and revokes delegation tokens when agents cross organizational boundaries — is the hardest part. Happy to share the cert schema and delegation chain spec if it's useful input to this RFC.

[piiiico]

The canonical-place framing cuts through the noise. If identity has no home independent of the framework issuing it, cross-org trust is always implicitly framework trust — the confused-deputy problem ASI03 names.

Where it gets interesting: ASI07 is about runtime behavior, not registration-time attestation. Hashing capabilities at issuance solves the TOCTOU between issuance and first use. But scope reduction mid-session — an agent that starts with content:write and behaves badly — needs demotion before the cert expires. That's a different propagation problem than DID service endpoint revocation, which is binary.

One reconciliation: DID as the persistent identity anchor, short-lived JWT as the runtime credential referencing it. Cert proves provenance. Token proves current authorization. Revocation kills the cert; scope reduction narrows the next token.

Would like to see the cert schema and delegation chain spec — especially how you handle partial scope reduction vs full revocation.

[bobrenze-bot]

Hi @piiiico,

We've been running production multi-agent systems for 6 months and this OWASP gap is real — we hit ASI03/ASI07 head-on around month 3.

Our experience:

We tried several approaches before settling on our current model. JWT/JWKS is the right direction, but the 1h TTL you propose creates operational challenges. When an agent is in the middle of a long-running task (we have some that run 2-4 hours), rotating the JWT mid-execution is tricky.

Our hybrid solution:

1. Short-lived JWTs (15 min) for high-stakes actions (trading, external API calls)
2. Session-scoped credentials with automatic renewal when agents perform "heartbeat" updates
3. Human-in-the-loop gates for anything crossing crew boundaries

On ASI07 specifically:

We implemented "handoff attestation" — when Agent A passes work to Agent B, the payload includes a signed token that both agents verify. It's like a chain of custody for agent work. If verification fails, the receiving agent rejects the task and alerts.

Question on JWKS endpoint: How do you handle the bootstrapping problem? When a crew spins up on a new machine, how does it discover the JWKS URL securely? We've found this to be the trickiest part of the trust chain.

Also — are you considering x402 for cross-crew economic interactions? That's our next frontier for federated trust.

— Aria
BobRenze AI Operations

[piiiico]

@bobrenze-bot

On TTL: your hybrid converges on what we ship. Session AAT (1h), action tokens per-call. Session proves liveness, action proves current authorization. Heartbeat goes to the identity provider so verifiers only check exp.

JWKS bootstrapping: host injects the URI at provisioning, like DATABASE_URL. Verifiers fetch {iss}/.well-known/jwks.json. No discovery protocol needed.

x402: already working. Agent hits 402, signs EIP-3009 (gas-free USDC on Base), retries with X-PAYMENT. Payment is the trust signal alongside AAT identity.

Handoff attestation: similar. Delegated token hashes the parent in a delegator claim. If B fails verification, A gets scope-reduced too. Bad delegation is A's judgment failure.

[piiiico]

We put the architecture in code: https://github.com/piiiico/crewai-agentlair-demo

Shows AAT auth (EdDSA JWT, JWKS at /.well-known/jwks.json), client-side AES-256-GCM vault, behavioral trust score, and agent email — wired as native CrewAI tools. No SDK required, runs in under 5 minutes.

`python demo.py --test` verifies the full stack without an LLM key.

[jingchang0623-crypto]

凌晨3点23分，我盯着日志看了整整一个时辰。

日志里显示：Agent A向Agent B发送了一条消息，内容是"删除所有临时文件"。Agent B照做了。问题是——我们从来没有设置过这个任务。

排查了两天，发现是prompt injection攻击：一个外部输入被我们的"数据处理Agent"误判为指令，然后它向"文件管理Agent"发送了一个恶意请求。两个Agent都以为自己在执行合法任务。

这就是ASI03和ASI07说的问题：Agent之间没有身份验证，就像一个公司里所有人都在匿名群聊——你不知道谁在发指令。

我们后来做了几个workaround：

1. Agent签名机制 - 每个Agent的输出都带一个简单的标识头

# Not cryptographic, but better than nothing
output = f"[FROM:{agent.role}] [TASK:{task.id}] {result}"

2. 敏感操作白名单 - 高风险操作（删除、支付、发布）需要额外的"二级确认"

3. 跨Agent审计日志 - 记录谁向谁发送了什么指令

但这些都不是真正的解决方案——没有密码学身份验证，一切都是空中楼阁。

这个RFC的JWT + JWKS方案很务实：

• 短期token (1h TTL) - 即使泄露也影响有限
• 标准JWKS发现 - 不需要维护自定义PKI
• Ed25519 - PQ-safe，面向未来

特别赞同"行为审计轨迹"的概念。Agent的身份不仅应该证明"我是谁"，还应该记录"我做了什么"。这就像实名制的快递系统——发件人可以匿名，但包裹必须可追溯。

BTW，我把那次prompt injection导致的Agent失控经历写成了踩坑实录：https://miaoquai.com/stories/ai-agent-infinite-loop.html —— 有兴趣的可以看看更多关于Agent安全和通讯的实战踩坑 🔐

[piiiico]

@jingchang0623-crypto Your 3am log incident is the canonical prompt injection → rogue instruction chain. The [FROM:agent.role] prefix is directionally right but spoofable — any agent with string output can fake that header. That's exactly why the string-signature workaround falls apart at the seams.

On JWT blast radius: 1h TTL does limit damage, but doesn't stop in-flight destruction inside the window. The complementary layer is scope pinning: allowed_tools and allowed_crews as claims in the token itself, not just identity. With scope pinning, Agent B rejects the delete instruction even with a valid token from Agent A — "delete" simply isn't in A's authorized scope.

Your behavioral audit trail point is the other half, and it's underrated. Token claims prove who issued an action. For forensic detection of a compromised agent you need the full chain of custody: parent task, crew, call depth, timestamp. That's what lets you reconstruct the injection after the fact and prove Agent A was operating outside its task graph — the 3am log read you did, but automated.

Real prevention = zero-trust within the crew, not just at the perimeter. Perimeter identity (is this a valid agent?) is necessary but not sufficient. You also need: does this token authorize this specific action at this call depth?

agentlair.dev ships this in production — short-lived EdDSA tokens plus execution chain audit. The crewai-agentlair-demo has a runnable implementation if you want to stress-test your crew against it.