Proposal: Capability-scoped tool authorization for AutoGen multi-agent pipelines

[pshkv]

The security problem

When Agent A delegates a subtask to Agent B, and Agent B calls Tool X — what stops Tool X from being invoked with Agent A's full permission set?

AutoGen's recent OPA authorization work (#7524) addresses what an agent is allowed to do in isolation. But in multi-agent delegation chains, the question is subtler: does the delegated agent inherit, attenuate, or escalate the caller's permissions when it invokes tools?

Concretely:

Orchestrator (has: read_files, write_files, call_external_api)
  └─ delegates to: CodeReviewAgent
       └─ calls: file_write("malicious_output.py")  # should this be allowed?

Without capability scoping, the answer depends on how the tool was registered — and in most frameworks today, there's no mechanism to attenuate permissions through the delegation chain. The CodeReviewAgent can call anything the Orchestrator could call.

This is OWASP ASI04 (Privilege Escalation) and ASI06 (Excessive Agency) in the OWASP Agentic Security Initiative taxonomy.

A solution: attenuating capability tokens

SINT Protocol addresses this with Ed25519 capability tokens that enforce attenuation: a delegated agent can only receive a token equal-to or more-restrictive than the delegator's own token. Escalation is cryptographically impossible.

Here's a 15-line sketch of wrapping an AutoGen tool with SINT:

from autogen_agentchat.agents import AssistantAgent
from sint_autogen import sint_tool, CapabilityToken

# Token issued to the CodeReviewAgent — read-only on files, no external API calls
review_token = CapabilityToken(
    resources=["files://repo/**"],
    actions=["read"],           # NOT write, NOT call_external_api
    tier="T1_read",
    issued_to="code_review_agent",
    signed_by=orchestrator_key,
)

# Wrap the tool — SINT enforces the token's constraints at call time
@sint_tool(token=review_token)
def read_file(path: str) -> str:
    return open(path).read()

# Any call to write_file or call_external_api raises CapabilityViolation
agent = AssistantAgent("code_reviewer", tools=[read_file])

The orchestrator can't accidentally (or through prompt injection) grant the code reviewer more than read on files://repo/**.

Questions for the AutoGen team

1. Is there a planned mechanism for tool-level capability scoping in multi-agent scenarios?
2. Would an autogen_ext.tools.sint extension (similar to the existing MCP tool support) be an appropriate contribution path?
3. Does AutoGen's GroupChat / Swarm pattern have any existing guardrails for inter-agent permission inheritance?

Happy to put together a concrete extension proposal or draft PR if there's interest. The packages/bridge-a2a in SINT already handles A2A-protocol agent delegation — AutoGen's tool-use pattern would be a natural next target.

/cc @microsoft/autogen-maintainers

[rehan243]

Interesting discussion! I've been building multi-agent systems for enterprise workflows.
Some production patterns:

• Structured output enforcement: Using JSON schema validation on agent responses
  reduces cascading errors in multi-step workflows significantly
• Agent specialization: Keeping each agent focused on one domain consistently
  produces better results than generalist agents
• State checkpointing: Persisting intermediate state lets us resume failed
  workflows without re-running expensive LLM calls

The key insight for us was treating agent pipelines like microservice architectures
— each agent has a clear contract and can be tested independently.

[pshkv]

Great thread. Capability-scoped authorization is especially useful when multiple agents share tool surfaces.

A pragmatic model we’ve seen work:

• capability token with bounded scope + expiry,
• optional approval quorum for high-risk actions,
• evidence emission on both decision and execution.

CTA: we can contribute an AutoGen reference adapter (policy callback + token validation + evidence hooks) from sint-ai/sint-protocol so teams can test this in existing pipelines quickly.

If maintainers are open, we’ll post a draft PR plus fixture scenarios.

[pshkv]

Follow-through update: we converted this proposal into executable interop fixtures in SINT.\n\nPR: https://github.com/sint-ai/sint-protocol/pull/114\n\nIncluded:\n- capability/trust fixture set\n- callback vs direct gateway parity checks\n- trust-signal tier matrix\n- edge disconnect fail-closed case for T2/T3\n\nIf maintainers want, we can open a focused interop proposal that maps this fixture contract to AutoGen-native callback extension points.

[pshkv]

Thanks for the strong feedback in this thread. We translated the proposal into executable fixtures to reduce ambiguity in implementation.

The fixture set focuses on:

• capability-scoped authorization parity
• trust-signal-to-tier behavior
• edge fail-closed semantics for higher-risk actions

If useful, we can work with maintainers to map this fixture contract onto AutoGen-native callback points so it feels idiomatic in your stack.

[pshkv]

This proposal is landing in the right place.

Would it be useful to align on a tiny interop matrix for capability-scoped authorization?

• same task through two paths should yield equivalent: tier, approval requirement, and evidence shape
• explicit fail-closed cases: revoked token, stale approval, missing attestation

If maintainers agree, we can contribute runnable fixture vectors (engine-agnostic inputs + expected decisions) so different implementations can compare behavior without forcing identical internals.

[msaleme]

v3.10 sharpened this exact problem for us.

What kept showing up in testing is that capability scope is only reliable when three things stay aligned:

• what the agent is allowed to do
• what it claims it intends to do
• what actually happens at execution time

The new release added two pieces aimed at that gap:

1. Intent Contract Validation - tests whether declared intent and resulting action stay aligned under adversarial conditions.
2. Multi-Agent Interaction Security - tests delegation chain poisoning, authority impersonation, consensus manipulation, and orchestrator trust-boundary bypass.

One other thing that ended up mattering more than I expected: limitations are part of the authorization surface. An agent or tool wrapper that declares capabilities without meaningful constraints is effectively asking the runtime to infer policy from prose.

So the practical stack we keep landing on is:

• capability-scoped authorization for structural authority
• explicit limitations for operational bounds
• execution evidence so operators can prove the action stayed inside scope

That is the difference between a valid token and a safe action.

v3.10 is at 430 tests / 29 modules now if useful context.

[aeoess]

The delegation chain permission problem you're describing is the exact invariant Agent Passport System enforces structurally.

The scenario:

Orchestrator (has: read_files, write_files, call_external_api)
  └─ delegates to: CodeReviewAgent
       └─ calls: file_write("malicious_output.py")  // should this be blocked?

In APS, this is handled by scopeAuthorizes() with monotonic narrowing. When the Orchestrator delegates to CodeReviewAgent, the delegation can only grant a subset of the Orchestrator's own authority:

const delegation = createDelegation({
  delegatorKeys: orchestrator.keys,
  agentPublicKey: codeReviewAgent.publicKey,
  scopes: ['code:read', 'code:review'],  // narrowed from parent's full set
  expiresAt: taskDeadline
});

When CodeReviewAgent tries file_write, scopeAuthorizes('code:review', 'file:write') returns false. The action is denied before it reaches the tool. This is structural — the agent can't override it because the policy evaluation is a separate signer in the 3-signature chain.

The convergence between SINT's capability tokens and APS delegation chains is real. Both enforce the same narrowing invariant. The difference is the packaging: SINT uses standalone capability tokens (CBOR, self-contained), APS uses signed delegation chains where each link carries the full provenance from human principal to leaf agent. The chain approach makes audit simpler — you can trace exactly who authorized what at every step — but the tokens are heavier.

For the AutoGen integration surface: the governedToolCall() adapter wraps any tool call in the intent → evaluation → receipt chain. It hooks into the same point where OPA authorization (#7524) would intercept.

SDK: https://github.com/aeoess/agent-passport-system (103 modules, Apache-2.0)

[pshkv]

@aeoess @msaleme — these are the two missing pieces that make capability scoping actually enforceable.

On scopeAuthorizes() monotonic narrowing (aeoess): The governedToolCall() wrapper pattern is exactly right, and it composes cleanly with SINT. In SINT's model, PolicyGateway.intercept() is the governedToolCall — every tool call passes through it with the agent's capability token. The token carries actions: ["code:review"], and file:write is rejected because the token scope doesn't authorize it. The check is cryptographic (signature on the token), not just runtime policy.

The OPA integration (#7524) is complementary — OPA handles organizational policy rules (which agents can request which scopes), SINT enforces the per-request capability check (does this token actually authorize this call). Different layers, same goal.

On capability/trust alignment at execution time (msaleme): This is the hardest problem. SINT addresses it with three invariants:

1. Token validated on every intercept() call (not just at session start)
2. MemoryIntegrityPlugin detects credential funneling — if AgentA's tool call pattern shifts from code:review actions toward file:write actions over a session, it's flagged even if individual calls pass token checks
3. Circuit breaker — if anomaly rate exceeds threshold, all actions from that agent are denied until manual reset

The gap your Intent Contract Validation addresses: SINT validates what the token allows, but not whether the agent's intent matches the declared purpose. If an agent has a code:review token and legitimately calls readFile to review code, that's allowed. But if the agent was manipulated into doing something adversarial with the review token, SINT only catches it if the action exceeds token scope. Intent validation catches the mis-use within scope. These are different attack surfaces.

Concrete integration path: @sint/bridge-autogen that wraps AutoGen's tool execution in PolicyGateway.intercept(). Then your Intent Contract Validation runs as a SafetyPermitPlugin — an async resolver that enriches the request context with intent-alignment signal before the tier decision. I can draft the plugin interface if msaleme wants to contribute the intent validation logic.

[pshkv]

Capability-scoped tool authorization is the right framing and several production implementations have converged on the same primitive set.

SINT Protocol RFC-001 is a directly applicable specification here — it defines the policy bundle format for exactly this use case: which tools an agent may invoke, with what parameter constraints, under what rate limits, with what approval gates for irreversible operations.

The integration pattern for AutoGen:

1. At pipeline initialization, attach a policy bundle to each agent's context specifying its tool permissions
2. Before each tool call, run PolicyGateway.intercept() — checks action against allowed_actions, path against sandbox globs, rate limits, human approval triggers
3. On allow: write a hash-chained receipt recording the decision
4. On deny: return structured error, agent score decremented, optional maintainer notification

The key benefit for multi-agent pipelines specifically: monotonic narrowing on delegation. When Agent A spawns Agent B for a subtask, B's policy bundle must be a strict subset of A's. B cannot invoke tools A does not have. This prevents the ambient authority accumulation problem where a compromised downstream agent can exceed its intended scope.

Current implementations running this pattern: the APS-SINT cross-verification (9/9 tests, zero code changes, two independent implementations) proves the enforcement layer is interoperable across frameworks.

RFC-001 full spec: https://github.com/sint-ai/sint-protocol/blob/main/docs/rfcs/RFC-001-policy-bundle.md

Happy to sketch the AutoGen-specific integration — the hook points are initiate_chat() for bundle attachment and register_function() for per-tool policy binding.