[Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF

[Mikhail Sergeev <[e-mail]>]

Stephen, Charles, Shawn,

Shawn's note exposes a distinction in the gating question that I think
is worth stating separately.

Exact, single-use, attenuated authority bounds what that grant
authorizes, where it is enforced. It does not establish that an action
attributed to c was not performed by b, where b created or hosts c and
can obtain or invoke c's signing capability. A message format can carry
the relevant control or evidence; it cannot create the required
independence.

A prevention claim at that boundary needs an enforcement point b does
not control and cannot bypass. A detection claim needs evidence b cannot
forge, together with a delivery or consistency mechanism under which b
cannot selectively suppress adverse evidence without the resulting loss
of assurance becoming observable. Independence alone is not sufficient
for either: a component outside b that is not required to authorize
every action in scope prevents nothing, and evidence whose delivery or
omission is not independently observable detects nothing.

Both mechanisms named upthread are instances rather than exceptions. A
remote-attestation-based design contributes to such a claim only where
the Evidence covers the property at issue; b cannot forge or substitute
the Evidence or the Attestation Result, or control the appraisal path,
including the applicable trust anchors and appraisal policies; and the
authorization path securely associates a sufficiently fresh Attestation
Result with the relevant Attester and action. RFC 9334 defines the roles
and the appraisal flow but permits roles to be aggregated into one
entity, so independence from b is a property of the deployment rather
than of RATS. Threshold signing provides a prevention dependency only
where b cannot reach the threshold without an independently controlled
signer that checks the exact operation against an approval policy and
can withhold its share.

I read Shawn's eighth mitigation as one case of this, and his
counter-chain suggestion as another by a different mechanism: divergent
chains support a detection claim only if the divergence reaches an
observer through a path b cannot selectively suppress without that
suppression becoming observable.

What is missing in the hard case is therefore not another field. It is a
point outside b that either enforces or observes, and no message format
creates one.

A charter-level gate can say that much without prescribing a mechanism.
Offered as text rather than as a position:

An architecture that claims to prevent or detect an intermediary b
acting as a downstream agent c must identify the independently
controlled enforcement or observation point on which the claim rests.
For prevention it must state why b cannot bypass that point; for
detection, why b cannot forge the evidence or suppress it without the
suppression becoming observable. It must define the behaviour when
that dependency is unavailable or cannot be validated. Where no such
point exists, the architecture does not establish prevention or
detection of b acting as c under a threat model in which b is
adversarial.

That is narrower than solving key custody, and it makes the assurance
claim and its trust boundary reviewable before a mechanism is chosen.

Best,
Mikhail

On Wed, Jul 29, 2026 10:09 PM, Shawn Sammartano <shawn.sammartano=
[e-mail]> wrote:

> Hi all,
>
> I'm new to the list, so sorry if some of this was already covered. I've
> spent a lot of time on the (a,b,c) problem. Here's where I got to,
> including the parts I can't solve. For those I'm mostly pointing at other
> people's work.
>
> I'd take Charles's point one step further. The password or private key
> should never travel. Not to c, and not through b. Once it moves, I don't
> see how you get safety back. b built c, and as noted upthread, b is in a
> fine place to cheat.
>
> So what travels instead? A permission slip that isn't worth much to steal.
> The one I built works like this:
>
> 1) It's tied to one exact request, down to the byte. The approver approves
> the exact bytes it read. Change anything afterward and the approval stops
> matching.
>
> 2) It works once. There's a ledger. A second use gets refused.
>
> 3) It carries a cap on how much harm the action can do. Anything
> unrecognized is treated as the worst case and refused. A delegated
> permission can never be broader than the one it came from.
>
> 4) Every use lands in a tamper-evident log that records what caused what.
>
> None of that needs my draft. You could build the same properties as an
> OAuth extension. The properties are the point.
>
> Credit where it's due, because most of this is not new. Macaroons have
> done offline narrowing since 2014, where whoever holds the token can add
> restrictions without going back to the issuer. Biscuit does the same and
> verifies with public keys, so its verifiers don't need a secret that would
> let them forge. So narrowing isn't mine and neither is public key
> verification. The part I haven't found in either, and I may have missed it,
> is that both are bearer tokens. Whoever holds one can use it again and
> again until it expires or gets revoked. The slip above is tied to one exact
> request and gets refused on the second use.
>
> I also read the drafts already in front of the group, and some of this
> ground is being worked. Apologies to those authors if I'm restating them.
> draft-bu-agentproto-security-principal-binding splits out which party
> verifies which claim, with binding, freshness and failure behavior stated
> per claim. draft-rampalli-cross-org-delegation-mapping already has human
> authorization bound to the exact action digest, failing closed when it's
> missing, stale, or bound to different bytes. That second one is close to
> what I described above, so please read me as agreeing with it rather than
> proposing something new. What I can add is running code and test vectors.
>
> > Wouldn't we also end up with OAuth tokens that allow 'c' to
> > just change a pwd or add an SSH key?
>
> With permission slips like this, I don't think so. There's nothing sitting
> around that says "may manage keys." The most a thief gets is triggering the
> one action that was already approved, once, on the record. b can still drop
> or delay traffic. I don't have a fix for that either. And I'm not saying
> this is the only way to do it. It's one I've built. A Go and a Rust
> implementation produce identical bytes against shared test vectors, so at
> least it's buildable. Draft at [1]. It's input, not an answer.
>
> Now the part I agree is hard. Key custody. If b builds c, then b can read
> c's key, so b can be c. No message format fixes that, mine included. Two
> angles look workable to me. None are wire-only and none are mine.
>
> First, protect the key.
>
> 1) Run c on hardware where even its creator can't read its memory,
> generate the key inside, and require proof of that before granting
> anything. That's the RATS and EAT work. Cloud enclaves already gate key
> services this way. One catch. "The key can't be extracted" isn't enough if
> b can still ask the hardware to sign. Use of the key has to be tied to the
> measured workload, which is what the proof is for.
>
> 2) Split the key between c and a service run by a, so c alone can't sign.
> Then every signature has to ask a's half, and a's half can say no each
> time. FROST does this today, RFC 9591, with implementations in more than
> one language. Post-quantum threshold signing isn't ready yet though.
>
> 3) Give c a key that lives minutes instead of months, and make it re-prove
> its environment to get a new one. A stolen copy goes dead fast.
>
> Second, assume the key does get copied and make that not pay off.
>
> 4) Catch the copy. Have every action from c carry a counter in a chain
> that only moves forward. If b copies the key and uses it while c is also
> running, you get two different chains claiming the same identity, and
> that's proof the key was duplicated. You can't tell which one is really c,
> but you can prove it happened and shut the identity down. This is a
> suggestion, not something I've built.
>
> 5) Make the key change after each use, in a way that can't be run
> backwards. A copy taken today stops working, and using the old copy shows
> up out of order.
>
> 6) Put a total budget on the whole delegation, not just on each
> permission. One use per approval still allows a thousand small approvals
> across a tree. One budget for the tree means when it's spent it's spent, no
> matter who holds which key.
>
> 7) For destructive actions, put a delay between approval and execution and
> let a cancel during the delay. It's also worth sorting actions by whether
> they can be undone at all. If you can't stop misuse, being able to reverse
> it inside an hour is worth a lot.
>
> 8) Don't let the creator be the only approver. If b creates c, b shouldn't
> be able to approve c's actions by itself. Two parties that don't share
> machines. Bank wires work this way for the same reason.
>
> That doesn't stop b from cheating. It makes cheating small and hard to
> hide. When b owns the machine, I don't know how to do better than that.
>
> On legacy targets. If the far end only understands the old password, then
> somebody who holds the password has to do the typing. The realistic shapes
> are the ones already named upthread, with the costs already named. c sends
> its one-shot exact request back to a, and a either does the operation
> itself or sets up a short-lived credential scoped to that one job. A
> protocol can make those round trips exact, single use, and logged. It can't
> make them go away. Getting rid of them means the target, or a gateway in
> front of it, learns to check delegated permissions. That's adoption work,
> not cryptography.
>
> One more thing, since this is all about long-term secrets. Traffic
> recorded today can be decrypted years from now, and long-term credentials
> are exactly what's worth recording. So these links should probably use
> post-quantum hybrid encryption. I have a draft on that side too [2], though
> it's hop by hop and does nothing about b in the middle.
>
> On the charter, the gating idea seems right to me, and it might be easier
> to state as properties than as a worked solution. Long-term secrets never
> pass through intermediaries or newly created agents. Delegated authority is
> exact, single use, no broader than its parent, and logged. Copying an
> agent's key is detectable. A key that can't be shown to be out of its
> creator's reach is treated as untrusted for anything that matters.
>
> One process note. I see the charter text is being worked on GitHub, and I
> also see that not everyone can follow GitHub over the next few weeks. If a
> property list like that is useful, I'm happy to open it as an issue there
> and post the same text here so it's visible to people who aren't watching
> the repo. Happy to help with test vectors too. And happy to be told where
> I'm wrong.
>
> [1] https://datatracker.ietf.org/doc/draft-bubblefish-naalp/
> [2] https://datatracker.ietf.org/doc/draft-bubblefish-npamp/
>
> Cheers,
> Shawn S.
>
> On 7/29/2026 5:44 PM, Stephen Farrell wrote:
>
>
> Hiya,
>
> On 30/07/2026 01:07, Charles Eckel (eckelcu) wrote:
>
> Hi Stephen,
>
> On Jul 29, 2026, at 4:31 PM, Stephen Farrell
> <stephen.farrell=[e-mail]>
> <stephen.farrell=[e-mail]> wrote:
>
>
> Hiya,
>
> On 29/07/2026 23:59, Charles Eckel (eckelcu) wrote:
>
> Please be sure to review and provide your comments on the Issues (https://
> github.com/ietf-artarea/charters/issues) that have been opened, the
> Pull Requests (https://github.com/ietf-artarea/charters/ pulls)
> that have been submitted, and the reviews and comments that have
> been provided. This input will be used to update the draft charter.
> In the interest of maintaining momentum, my goal is for this update
> to be posted to the datatracker and to the list for additional
> review and discussion by early next week.
>
>
> I won't have time to follow GH issues/PRs in the coming weeks. (It
> is vacation time.)
>
> My main charter comments though might be ones I can express now:
>
> - I'm v. unclear that IETF work in this space would prosper due to other
> efforts having far more adoption. I don't however object to lots of
> other people wasting lots of time if that's the case, but it'd seem
> sub-optimal.
>
> - If agents can talk to one another in paths or trees, then before
> chartering a WG I would suggest we need to have an answer for this
> question: If (a,b,c) is a comms path between agents (perhaps within a
> tree) and if 'c' is actually a newly created entity, but one that needs
> access to a long-term secret credential accessible at 'a' (e.g. pwd
> or SSH private key) and where that credential must not be exposed to
> 'b' nor easily abused - then how's that going to work?
>
>
> I agree that agentproto needs an answer for this. My take on it is
> that ‘c’ should not be able to access "a long-term secret credential
> accessible at ‘a' (e.g. pwd or SSH private key)”; rather, ‘a’ should
> have a mechanism to authorize ‘c’ to do something specific on behalf
> of ‘a’.
>
>
> I can see why you'd go there. However, it's unclear to me that
> OAuth can effectively solve the problems.
>
> I should emphasise that the scenario I posited is one where 'b'
> creates 'c' and so is in a fine place to cheat;-)
>
> Firstly, I'm not sure how OAuth could stop 'b' from getting at
> the token(s) we'd only like to be visible to 'c'.
>
> Wouldn't we also end up with OAuth tokens that allow 'c' to
> just change a pwd or add an SSH key? (In practice I mean, for
> many instances of 'c'.)
>
> And (despite hating the idea), I'm unclear that instances of
> 'c' could in practice do what's needed without access to a
> pwd or SSH private key or equivalent. (One might posit use of
> OTPs or ephemeral SSH private keys perhaps, at the expense of
> either callbacks to 'a' or needing 'a' to do some setup with
> the targets with which 'c' interacts, but that's where we
> maybe get beyond the remit of the OAuth WG.)
>
> My understanding is that the OAuth WG intends to define such a
> mechanism, per this statement in its updated charter, "Complex
> Delegation: Developing new mechanisms or/and extensions for
> authorization of automated agents working on behalf of users,
> including addressing scenarios where automated agents act across
> multiple administrative domains.”
>
>
> It's not clear to me that that's something this putative WG can
> delegate to the OAuth WG. I may well be wrong, or just unable to
> grok the complexity inherent in an OAuth solution though;-)
>
> It'd also be quite the challenge to explain the security of such
> an OAuth solution I think, and it'd be liable to be a solution
> that easily resulted in mis-configuration, or in the opposite
> of least-privilege.
>
> All that said, I do accept that a good IETF OAuth scheme might
> well be better than what MCP or A2A people independently invent.
>
> I'm also not asking that the charter text include a worked out
> solution. But I do think the charter text ought have solving
> such issues as a gating factor before publication.
>
> Lastly - I'm not asking this to be awkward (honest:-), but it
> seems a plausible scenario, and is one I dunno how to solve.
>
> Cheers,
> S.
>
>
>
> Cheers, Charles
>
> (And the more obvious general cases too of course:-) If there's no good
> answer for that, then I'm sorta strongly against chartering a WG as
> we'd be inevitably enabling pick-pocket agents. (And it'd just be
> smelly;-)
>
> I do not think OAuth or any other existing IETF technology by itself
> provides an answer to the credential question above.
>
> Thanks, S.
>
>
>
>
>
>
>
> _______________________________________________
> Agentproto mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> --
>
> *Shawn Sammartano*, Founder
> BubbleFish Technologies, Inc.
> Sovereign AI infrastructure
> bubblefish.sh
>
> _______________________________________________
> Agentproto mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>