Suppose you tell an agent: move Acme to At Risk, create a task for the account owner, and prepare a renewal plan. The agent does exactly that.
Wha...
For further actions, you may consider blocking this person and/or reporting abuse
The hard part of agent identity is separating 'who was asked to do this' from 'who actually did it', because once an agent can call other agents or tools the attribution chain gets long and easy to break. What I would anchor on is a signed, append-only audit record where every action carries both the human principal it was delegated from and the agent credential that executed it, plus a scope that says which actions are allowed without re-confirmation. That turns 'the agent did X' into something you can defend in an incident: non-repudiation for the human, least privilege for the agent, and a clear line where autonomy ended and explicit approval began. The MCP boundary is exactly where this matters most - a tool call crossing it should carry the authority context with it, not just the payload.
Agreed, and the length of the chain is exactly what breaks naive logging. Once it's agent -> MCP server -> CRM -> another agent, "who was asked" and "who did it" can be three hops apart.
Your "scope that says which actions are allowed without re-confirmation" is the workflow-policy part of the intersection in the post, and I like framing it as the line where autonomy ends. GitHub's agent commits are the closest thing I've seen to your signed append-only record: agent as author, human as co-author, signed, with a link to the session log.
On the MCP boundary: audience-bound tokens stop the confused deputy, but they don't carry the delegation chain across hops yet. How would you propagate it when one agent calls another? Nested actor claims, or a correlation ID into the audit store?
Both, but the claim has to travel with the call, not just the ID: a correlation ID is only as trustworthy as the store that keeps it. In practice we sign each hop, so the child agent re-signs the parent claim with its own key and the audit store can verify the delegation without trusting any single agent.
Signing each hop is the cleanest answer I've seen to this, because the audit store never has to trust the agent's own story. It turns the delegation chain into something closer to a certificate chain.
The rule I'd pair with it: each hop can only narrow the scope it received, never widen it. Then a signed chain proves not just who delegated to whom, but that nobody along the way granted themselves more than they were given.
How do you handle keys for short-lived agents? A fresh key per task, or a longer-lived key per agent that signs task-scoped claims?
Fresh key per task, with the longer-lived one only as a bootstrap: the per-task key is minted at delegation time and dies with the task, so a compromised agent cannot sign claims outside its own run. Expiry then does the revocation for you - there is nothing left to revoke once the task is closed.
Really thoughtful breakdown of the actor-authority split — I've been thinking about this a lot. One place this distinction becomes operationally concrete is when an agent needs to authorize a payment. The agent can reason about what to pay and propose a transaction — that's the actor layer. But the signing key that releases the funds has to live in a separate context, because the authority to spend can't be delegated to the same principal that decided what to spend on. That boundary is where your two-principal model meets moving money. The agent gets the identity you asked for, but the wallet doesn't hand over the keys — it evaluates the proposal and confirms or rejects. This is the design constraint any production agent payment system has to solve, and the frameworks that preserve the actor-authority split in the payment domain are the ones that will survive an audit.
Payments are probably the cleanest example of why the split matters. With a CRM field, conflating actor and authority gives you a misleading audit log. With money, it gives you an agent that can approve its own spending.
What you describe maps nicely onto the "permissions as an intersection" idea: the agent can propose anything within its own scope, but the transaction only goes through if the authority side, in your case the wallet, independently agrees. The agent never holds the power to commit, only to ask.
The part I find interesting is the middle ground. Most teams won't want a human confirming every small payment, so the authority often becomes a policy ("auto-approve under €500 to known vendors"). That's the nightly-policy case from the post: the actor is still the agent, but the authority is a rule someone signed off on earlier. For the audit, you then need three things recorded, not two: who acted, under which authority, and which policy version approved it.
How are you handling that in practice? Explicit confirmation per transaction, or pre-approved limits?
The intersection formula is the bit I would push hardest on, specifically when it gets evaluated. If the user's half is copied into a token when the task starts, a long-running delegated agent keeps Alex's access after Alex is moved off the account or leaves the company. I work at Permit, so I spend a lot of time on this one: the check on each tool call should look up the user's current permissions, alongside the agent's own grant and the workflow policy. Token exchange tells you who the subject and actor are. It cannot tell you whether the subject still has the right an hour later.
For the 03:14 autonomous case I would also log which version of the renewal policy allowed the action. "Authority: renewal policy" is hard to audit once someone has edited the policy.
This is the right place to push. Copying the user's half into a token at task start quietly turns the intersection into a snapshot, and a long-running agent ends up acting on authority Alex no longer has. Evaluating all three parts on every tool call is the only version that holds. Token exchange answers who; only a live policy check answers whether they still can.
And yes on the policy version. Someone made the same point in another thread here about payments: "authority: renewal policy" means little once the policy has changed, so the record needs the version that approved it.
Curious how you handle revocation mid-task: does the agent stop at the next tool call, finish its current step, or escalate to a human?
Suggest per-agent workload identities with short-lived, task-scoped credentials and logging the delegating user on every tool call, so audit trails survive prompt-injected actions.
Agreed on all three, and prompt injection is a good stress test for the split. An injected action still runs under a real identity and real authority, so the log looks legitimate unless it also records what triggered it.
That's the piece I'd add to "log the delegating user": log the input that led to the tool call too, or at least a reference to it. Then an incident review can tell "the agent did what Alex asked" apart from "the agent did what a document it read told it to do", which look identical if you only record who and on whose behalf.
Do you capture that provenance today, or mainly the identity and scope?
In practice: a long-lived key only mints the task key, and the task key dies with the task. That keeps the compromise surface small - a leaked key has an expiry and a narrow scope by construction - but it moves the hard problem to revocation latency: if the parent principal is deprovisioned mid-task, the already-minted child key is still valid until it expires, so the chain needs a live policy check at the tool-call boundary, not just a signature check.
Each signature has to cover the payload, not just the hop. Otherwise you prove who signed, not what was said.