How are you handling agent authentication in multi-agent systems?

[lujainkhalil]

Been building multi-agent systems and kept running into the same problem, agents calling APIs with hardcoded service
account tokens or borrowed user credentials. No standard way to know which agent made a request, who's accountable for it,
or whether a stolen token is being replayed.

Built a library to address this: proveyouragent. Each agent gets an Ed25519 keypair, every request is signed with DPoP so stolen tokens are useless without the private key, and delegation chains let orchestrators pass scoped permissions to sub-agents with cryptographic linking.

pip install proveyouragent

https://github.com/lujainkhalil/proveyouragent

Curious whether this maps to problems people are hitting when building with AutoGen, especially in multi-agent pipelines where an orchestrator is delegating to specialist agents. How are you handling auth and accountability today?

[Michael 'Mike' K. Saleme (msaleme)]

Ed25519 + DPoP is a solid foundation — we need more of this in the ecosystem. One thing I'd flag from our testing: cryptographic identity solves authentication, but it doesn't solve authorization drift in multi-agent pipelines.

In our Autogen security harness, we found cases where an agent with a valid keypair was tricked — via prompt injection in task metadata — into delegating scoped permissions to a spoofed downstream agent. The signatures checked out, the DPoP binding was correct, but the authorization decision was manipulated at the application layer.

What we've learned: the delegation chain needs two independent bindings:

1. Cryptographic: who signed this delegation (your DPoP + Ed25519)
2. Semantic: what capabilities were actually delegated, expressed in a format the receiving agent can enforce without parsing natural language

If the capability scope lives only in human-readable task descriptions, the chain is vulnerable to semantic attacks. Encoding it in a machine-verifiable format — we're experimenting with this as part of our Skill Security Protocol — closes that gap.

Would love to see how proveyouragent handles the authorization-boundary question. Have you looked at capability-scoped tokens rather than identity-scoped ones?

https://github.com/msaleme/red-team-blue-team-agent-fabric

[datawithdev]

just curious.. is delegation of any permissions from an agent to a sub-agent part of your workflow.. I wonder if this can be prevented if every agent (including subagent) must get its identity and authorization from a central store such as Entra/Okta etc..

[Michael 'Mike' K. Saleme (msaleme)]

datawithdev Yes — sub-agent delegation is exactly where the static-identity model breaks, and your instinct is right that every sub-agent needs its own identity. But identity alone isn't the whole answer; two things have to hold together:

1. Identity per sub-agent, not inheritance. A sub-agent shouldn't act under the parent's credential — it gets its own workload identity issued at spawn (a SPIFFE/SPIRE SVID, or an OIDC-bound service account), so you can always attribute which agent did what. Shared or inherited credentials are what make nested delegation ungovernable.

2. Attenuation, not just authentication. Proving a sub-agent is who it claims doesn't stop it doing more than the parent intended. The delegated token has to be scoped down from the parent's — capability attenuation (macaroon-style caveats, or a token exchange per RFC 8693 that can only narrow scope, never widen it). Each hop delegates a strict subset of its own authority.

So I'd reframe "prevent" as "bound and make provable": you don't block delegation, you make every hop carry its own identity and a strictly-attenuated slice of the parent's authority, verified at the tool boundary. Then an over-reaching sub-agent is a policy denial at the point of action, not a forensic question after the fact.

[datawithdev]

Michael 'Mike' K. Saleme (@msaleme) appreciate your comments.. looked at some of your repos.. thanks for your contributions

[Ishita Tyagi (ishita-0301)]

Really interesting approach. Identity and delegation are definitely becoming bigger problems as multi-agent systems get more autonomous.

One thing I've also found useful is thinking beyond who made the request to what the agent does next. Even with good auth, agents can still get stuck in retry loops or repeatedly make bad calls. I've been exploring https://github.com/FailproofAI/failproofai for that side of the problem since it focuses on runtime reliability and execution guardrails.

Feels like the two ideas complement each other nicely.

[Michael 'Mike' K. Saleme (msaleme)]

The hardcoded-service-account pattern is unfortunately the default in most agent frameworks right now, and it breaks down as soon as you have more than two agents or any nested delegation.

What we have found testing identity and auth vectors across MCP, A2A, and generic multi-agent setups:

1. Agents need their own identities, not shared service accounts.
A shared token means you cannot tell which agent made a request, and revoking one agent means revoking all of them. We test for this with identity-metadata availability (ID-001) and spoofing resistance (ID-002) — basically, can the agent prove who it is, and can an attacker forge that proof?

2. Tokens must be short-lived, scoped, and bound to the delegation chain.
If orchestrator A delegates to worker B, B should receive a token scoped to only what A was authorized to delegate, with an "on behalf of" chain embedded. We test OAuth token scope escalation (AUTH-003) and delegation-chain validation (AUTHZ-002) — can B use its token to call something A was never allowed to touch?

3. Use workload identity (SPIFFE/SPIRE) instead of static secrets.
SPIFFE gives each agent a cryptographically verifiable identity tied to its runtime, not a repo secret. It maps cleanly to multi-agent: the orchestrator mints a SPIFFE ID, workers get derived IDs, and every call carries an automatically short-lived SVID. Our harness checks for SPIFFE workload identity support (STD-002) and OAuth 2.1 / OIDC discovery endpoint presence (STD-001) because without discovery, agents cannot rotate or validate keys automatically.

Practical starting point for AutoGen:

• Replace static API keys with SPIFFE agents or OIDC-bound service accounts.
• Wrap every tool_call with an identity context: (caller_id, caller_token, delegation_chain).
• Validate at the tool boundary, not just the agent boundary — an agent may be trusted, but the specific tool it is calling may require narrower authorization.

We have concrete test vectors for unauthenticated access prevention, expired-credential rejection, least-privilege enforcement, and scope escalation in an open multi-agent security harness. Happy to share if useful.

[Eray Özer (ozereray)]

The distinction between authentication and authorization drift is really important.

A sub-agent can have a perfectly valid identity and still receive a delegation that exceeds the authority intended by the parent agent.

I'd therefore want the delegation itself to become a policy-controlled object rather than treating identity as the authorization boundary.

Something like:

agent identity
→ delegated capability
→ requested action
→ runtime policy
→ execution

We're working on a similar model with Aegisora, particularly around making the final action decision independent from the agent's own reasoning.

That seems increasingly important as multi-agent systems move from “agents talking to each other” toward agents actually granting capabilities to other agents.

[Ranknod (ranknodofficial)]

"Ed25519 + DPoP gives you a strong answer to “which workload/key made this request?”, but I’d keep the authorization object separate from that identity proof.

For delegation, each hop can issue a task-scoped grant whose authority is no broader than the parent’s delegable authority. The final tool verifies the signature chain plus the current call: audience, action, resource, constraints, TTL, delegation depth and any revocation state.

That gives you two independent properties:

1. Authentication/proof-of-possession: this request came from the expected agent key.
2. Authorization: that agent currently has delegated authority for this operation.

I would also avoid passing the end user’s bearer token through the agent chain. If possible, exchange it for workload/task-specific credentials at each boundary.

The useful failure test is simple: compromising a specialist agent key should not let the attacker exercise the orchestrator’s full authority."