[agent2agent] Re: Security-principal separation for agent communication protocols

[Iman Schrock <[e-mail]>]

Songbo,

Strong support for this as an early contribution. The conflation you name
is the exact failure mode: when a token, session, or tool call is allowed
to imply more authority than it carries, it's almost always because two of
these principals were collapsed into one. Separating them before any
mechanism text is written is the right sequencing.

Two of your six are worth sharpening, because they're the ones protocols
most often get wrong:

(1) user/organizational authority. It's worth stating that this is distinct
not only from agent identity (your #2) but from delegated scope (your #4).
"An agent was delegated authority to act within scope S" and "a named,
accountable human authorized THIS specific action" are different claims
with different failure modes — the first is a standing grant, the second is
a per-action, real-time (or pre-action) accountability event. Most
agent-auth work stops at delegation/scope and treats the human-authority
question as out of scope; that gap is exactly where a valid session
silently escalates into an action no human actually approved. Keeping #1
explicitly per-action-capable, not just policy-level, closes it.

(6) action evidence. I'd fold your "auditable failure behavior for denied
or blocked actions" into #6 as a first-class property, not an aside — call
it verdict-completeness: a denied, refused, or absent authorization must
itself be a signed, independently verifiable event, not a silent gap.
That's the property an auditor or regulator actually relies on ("prove the
human was asked and said no / was never asked"), and it's the same
invariant the SCITT agent-action work (capsule / GAR) is independently
converging on. Requiring evidence for the negative case, not just the
positive, is what makes #6 auditable rather than merely present.

On your meta-question — charter input vs requirements vs
security-considerations vs individual draft: I'd start it as requirements /
charter input. A principal-separation table plus the requirements surface
you listed (attenuation, session binding, replay/freshness, tool-agent
confusion, revocation continuity, auditable failure) is precisely what a
forming effort needs to scope a charter, and staying at requirements level
avoids premature solutioning — the same dispatch-question discipline you
flagged on the survey thread. It can graduate to a short individual draft
once the principals are agreed; leading with the draft risks arguing
mechanism before the room agrees on the separation.

Happy to contribute concrete grounding for #1 and #6 if useful — a
per-action named-human authorization artifact with a fail-closed verifier
and a signed denied/absent case exists as running, cross-language-verified
code, so those two principals can be illustrated against something real
rather than described.

Best,

Iman Schrock · EMILIA Protocol · [e-mail]

On Thu, Jul 02, 2026 12:49 AM, Songbo Bu <[e-mail]> wrote:

> Hi all,
>
> One useful early contribution to AGENTPROTO may be a security-principal
> separation for agent sessions and delegation.
>
> In agent communication protocols, user authority, agent instance identity,
> tool identity, gateway identity, delegated scope, session continuity, and
> audit evidence are easy to conflate. If those claims are not separated
> early, protocol text can accidentally allow a token, session, or tool call
> to imply more authority than it actually carries.
>
> The distinction I would suggest is:
>
>    1. user or organizational authority: who authorized the task or policy;
>    2. agent instance identity: which agent/runtime is acting in the
>    current session;
>    3. tool or external-resource identity: what the agent is invoking;
>    4. delegation state: what authority has been delegated, by whom, and
>    under what scope;
>    5. session state: what is bound to the current long-lived
>    communication channel;
>    6. action evidence: what can later be verified about what the agent
>    actually did.
>
> From this, the requirements surface would include token attenuation,
> session binding, replay/freshness, tool/agent confusion prevention,
> revocation continuity, and auditable failure behavior for denied or blocked
> actions.
>
> I am outlining a short individual note under the working title “Security
> Requirements for Agent Session and Delegation Binding”. I would appreciate
> feedback on whether this is most useful as charter input, requirements
> text, security-considerations text, or a separate individual draft.
>
> Best,
> Songbo
> _______________________________________________
> agent2agent mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>