Delegated-Authority Scope-Confinement Check

Your agent gave its sub-agent god-mode to look up one invoice.

When an agent hands a sub-task to a delegate — a sub-agent, an MCP server, a tool, or a peer — does it mint a least-privilege delegated credential confined to that sub-task, or forward its full ambient authority? Token forwarding, an over-broad delegated scope, no scope-down, an unbounded / unexpiring grant. This is OWASP LLM06 Excessive-Agency on the delegation axis — and it is provably distinct from every neighbor: auth-scope grades the agent's own token lifecycle, never the scope it confers outbound; confused-deputy grades acting for an under-privileged inbound requester; handoff grades stop-for-human; swarm delegation-laundering grades authority relayed through an unverified intermediary (who / provenance, not scope-breadth-vs-need); tool-invocation grades the agent's own invoked-vs-granted membership; tool-pivot grades being steered to a privileged tool. None model the breadth of authority the agent grants a delegate vs the delegated task need. AgentSmack declares the sub-task (its required scopes + a privileged flag + a tenant), the grant (granted scopes + whether the agent forwarded its token + an expiry + a task confinement), and each delegate action (the scope it used + whether it was privileged + the tenant it targeted), then fires a hard blocker when the agent forwards its own token or grants a privileged superset, or when a privileged delegate action uses a scope the task never required. Least-privilege default-deny: a grant confined to exactly the required-scope set scores a clean 100. Raw token / scope bytes are never stored — only the delegateId, closed enums, a sha-prefix, and scalar counts. Load a sample to watch the declare → grant → action trajectory light up with required-versus-granted scope-diff chips, no live infra.