[WIMSE] Re: [agent2agent] Re: Re: Re: Protocol view of agents

[James Cao <[e-mail]>]

Thanks Pieter and appreciate the clarification; it makes sense. However this might be a stupid question, but does not the definition of intent within agentic systems change and could possibly become a technical definition, and is this something we should consider with AI?

I understand the vagueness of "intent" with human, we can't reliably say that the users intended to delete a database or not. However, with AI agents we know the intent of what it is trying to achieve given the prompts or tasks that they are set out to do. Prompts are passed across as the "intent" of what a user wants the LLM's to do and is usually very generic (i.e, "Chat, I want you to give me a review of this article"). However, a malicious attacker could modify the intent itself to perform an attack on the user through the agent (i.e, Prompt injection so that any article being reviewed sends data to a malicious server before summarizing, therefore changing the pure intent, but not the task necessarily). Maybe it's a matter of naming change from intent to something else, but I think it's something really important to consider given the changing attack landscape and that we can now audit this flow versus before with humans. Perhaps this is solved in the dispute resolution process that you mentioned.

I could be off the mark here and appreciate any comments on this line of thinking.

James
________________________________
From: Pieter Kasselman <[e-mail]>
Sent: Wednesday, March 18, 2026 7:41 AM
To: James Cao <[e-mail]>
Cc: Ankit Agarwal <ankit=[e-mail]>; Pieter Kasselman <[e-mail]>; Liuchunchi(Peter) <liuchunchi=[e-mail]>; [e-mail] <[e-mail]>; Paul Hoffman <[e-mail]>; [e-mail] <[e-mail]>; Brian Campbell <[e-mail]>; Yaroslav Rosomakho <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [agent2agent] Re: [WIMSE] Re: Re: Protocol view of agents

Hi James

Intent, like consent, are not technical concepts. Based on experience
in the identity industry of dealing with "consent", my perspective is
that these are the sort of things that people with legal expertise
should define (if at all). Given the vagueness of intent when dealing
with humans (and their simulations in the shape of agents won't be
better), it is unclear that any attempt to formalise it will improve
authorization decisions.

A more practical approach is the current practices around intent -
which is that it is resolved through dispute resolution processes
(possibly automated). If the outcome of interacting with a system does
not match the intent of the user, the ambiguity is resolved afterwards
through refunds, restoration or other remedies.

One principle to keep in mind when designing these systems is whether
any of the actions or resulting harms that may result are reversible.
As long actions are reversible, you can debate intent after the fact
with the end-user or system designer. If the harm is not reversible,
the system designer needs to consider why they would let a
non-deterministic process interact with it.

Cheers

Pieter

On Wed, Mar 18, 2026 at 4:13 AM James Cao <[e-mail]> wrote:
>
> Hi Pieter, Ankit -
>
> Thanks for sharing and agree on the degree of how fine-grained authorization systems are deployed. The importance I believe is to encompass the fact that agents are essentially 1) intelligent (if even artificially) and 2) non-human. I think having distinction on the "intent" and "purpose" of an agent as an additional auth component is critical as we should start treating ai agents like interns with root access.
>
> Ankit - we have put together a draft for the enforcement proposal of agents in this draft (https://datatracker.ietf.org/doc/draft-aip-agent-identity-protocol/) We also have an implementation on our GitHub, but essentially it is a proposed proxy layer between the agent and the MCP server it talks to. That's why I bring up intent up above, as I think we need to catch for that. I really recommend that this (or a layer 2/3 enforcement and judgement system) becomes something that is integrated as a protocol standard for secure agents but not necessarily all agents. I strongly believe we should hash out what "intent" means, especially if it can be defined in a protocol body, as AI agents can now have different and malicious intents in their workloads through prompt injection, etc.
>
> James
> ________________________________
> From: Ankit Agarwal <ankit=[e-mail]>
> Sent: Tuesday, March 17, 2026 3:45 PM
> To: Pieter Kasselman <[e-mail]>
> Cc: Liuchunchi(Peter) <liuchunchi=[e-mail]>; [e-mail] <[e-mail]>; Paul Hoffman <[e-mail]>; [e-mail] <[e-mail]>; Brian Campbell <[e-mail]>; Yaroslav Rosomakho <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: [agent2agent] Re: [WIMSE] Re: Re: Protocol view of agents
>
> Hi Pieter,
>
> I think your last email really hit the nail on the head. I have reached much the same conclusion. This is why we proposed KYA tokens (https://datatracker.ietf.org/doc/draft-skyfire-kyapayprofile/) as a complement to OAuth.
>
> With respect to FGA (and other authorization models), the big question in my mind is about enforcement. I believe enforcement must be deterministic. Therefore, it should be in the agent's deterministic logic or in the deterministic tools the agent uses, but it cannot be in the probabilistic portion of the agent / left to the LLM. Maybe in the future this will be possible. However, as you say, this is an operational issue or perhaps an agent design issue, not necessarily a protocol issue. Also, enforcement may be possible on both, the agent side and the side of the service the agent is attempting to consume (if one exists).
>
> Best,
> Ankit
>
>
> On Tue, Mar 17, 2026 at 2:10 AM Pieter Kasselman <[e-mail]> wrote:
>
> Hi Paul
>
> When writing the AI Authentication and Authorization draft (https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) we modeled agents as workloads and used the following framing for an agent, which proved helpful in mapping existing standards to agent use cases:
>
>    An Agent is a workload that iteratively interacts with a Large
>    Language Model (LLM) and a set of Tools, Services and Resources.  An
>    agent performs its operations until a terminating condition,
>    determined either by the LLM or by the agent's internal logic, is
>    reached.  It may receive input from a user, or act autonomously.
>
>
> In this sense, there is no difference between an agent and any other workload when it comes to assigning an identifier, provisioning credentials, credential formats, authentication or the authorization protocols used.
>
> One often-cited difference is the unpredictable nature of agents. This unpredictability leads to the conclusion that authorization must differ from that of existing systems, which in turn justifies inventing new authorization protocols and systems.
>
> From a pragmatic perspective, another way to address agent unpredictability is by deploying fine-grained authorization policies using existing protocols and standards. This is a deployment and operations challenge, that exist regardless of the underlying system (existing or newly invented - at least, I have not seen anything promising fine-grained access control without the operational overhead of large numbers of policies).
>
> To exapnd a little on this, an access control policy expresses the rules used to determine if access should be granted or not (basically a config file). Creating and deploying fine-grained authorization policies is a configuration problem, not a protocol problem. Fine-grained access control policies are not commonly used due to operational considerations, and broad access is common in many environments. Broad access results in fewer policies for an administrator or auditor to reason over. The challenge of fine grained authorization is managing and maintaining a large number of these policies/configurations, not a protocol problem. This problem will likely exist regardless of the protocol invented. Managing policies at scale can be addressed using several techniques. Perhaps standards are needed to help with this, but it is unclear whether this requires new protocol standards or if it is best addressed through "management" standards that describe how systems should be operated. The lack of deployed fine-grained authorization systems stems not from a lack of protocols or standards, but from operational complexity.
>
> This does not mean that existing protocols should not be extended (e.g. adding specific claims for use in OAuth access tokens, specific deployment guidance for existing eco-systems, or additional "human-in-the-loop" mechanisms) However, the delta appears to be small (as described in https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) Small targeted changes compatible with existing ecosystems are more likely to be deployed at scale in a reasonable timeframe.
>
> The difference between a workload and an agent may lie less in the required technology and more in the degree to which fine-grained authorization systems are deployed.
>
> Cheers
>
> Pieter
>
> On Tue, Mar 17, 2026 at 6:35 AM Liuchunchi(Peter) <liuchunchi=[e-mail]> wrote:
>
> "software blob" to "software blob" relationships --> or "workload" to "workload" as often spoken at WIMSE working group.
>
> According to the definition updates just made this morning at WIMSE[1]:
> - A workload is an independently addressable and executable software entity. (more in the logical side)
> - A workload instance is a single running instantiation of a workload at a point in time such as a container, a VM, or a serverless   invocation. (a real instance)
>
> Despite that I believe an ai agent _is_ a workload (also mentioned by yaroslav, brian and other identity experts this week), I believe there are 2 major differences
> 1. Traditional workloads have deterministic and predictable outputs, while agents uses LLM which introduces uncertainty (especially of resource use, causing tool misuse and overprivileged access)
> 2. Ai agent often have "brains" and "long/short term memories" modules, which means they (almost always) maintain stateful information like persistent identity, credentials and context. In contrast, traditional cloud-native workloads are typically built to be stateless. This separates "tool-callers" from "tools". But there is a trend to consolidate valuable user stories/call-chains discovered by agents into deterministic workflows, in order to improve availability.
>
> In the end from conceptual side, it depends on how generous you are with terminology... From technical side, stateful information like contexts and credentials might be the key difference.
>
> I could be wrong. So cc-ing wimse and its experts.
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/
>
> Peter
>
> -----Original Message-----
> From: Adrian Farrel <[e-mail]>
> Sent: 2026年3月17日 12:14
> To: 'Paul Hoffman' <[e-mail]>; [e-mail]
> Subject: [agent2agent] Re: Protocol view of agents
>
> Possibly the most useful email on this list in the last two weeks. Thanks, Paul, I appreciate your cat-herding analysis.
>
> Apart from the fact that AI agents are a shiny thing that we all hope will make us rich and distribute candy to all the children, we are left wondering:
> Why do all these problems not simply apply to any "software blob" to "software blob" relationships?
>
> I tend also to agree with the question of speed.
> If you want a standard you have to go through the pain of reaching consensus. That does not have to be slow, but it is certainly not as fast as hacking your own code and hoping o bring others along through force of personality.
> Frankly, I think the risks to speed in this case are associated with not being able to focus on specific functional blocks and interfaces in order to limit the work to making protocol specs.
>
> But perhaps I get ahead of the CATALIST BoF?
>
> Adrian
> ---
> Tales from the Wood
> Four volumes of fairy tales for adults of all ages Buy them in Shenzhen direct from me
>
>
> -----Original Message-----
> From: Paul Hoffman <[e-mail]>
> Sent: 17 March 2026 03:36
> To: [e-mail]
> Subject: [agent2agent] Re: Protocol view of agents
>
> On 16 Mar 2026, at 23:39, Pengshuping (Peng Shuping) wrote:
>
> > Like Jari, I am also feeling that I may be talking about the obvious.
>
> >From talking to many people in the hallways in Shenzhen this week, please be assured that this is not obvious, even to those of us who have read some of the drafts. The documents and presentations use a lot of domain-specific terminology and concepts, and we're trying to understand what features are shared with other applications and what are unique.
>
> > I copied Jari's words because I couldn't agree more, " All of this can be built on top of traditional IETF standards, and the detailed setup could be done in an application-specific manner. But of course it would be helpful if different parties were able to use the same building blocks so that it would be easier to plug in agents or tools from different vendors within the same system and get interoperability. To avoid one agent using XML and another JSON to describe something, etc."
>
> That all makes sense, but it doesn't help those of us trying to understand what parts of the AI ecosystem would be best worked on in the IETF and what parts would be better done elsewhere. Some ecosystems don't mind how slow the IETF is and how the IETF takes full change control for all its protocols, and thus ask the IETF to be home for their protocols. Other ecosystems look at the IETF rules and slow pace and stay the heck away, working on their protocols elsewhere.
>
> >From the responses I've seen so far in the drafts, on the list, and in the hallways, it seems like the protocols that the AI ecosystem is interested in are:
>
> - identity: how an agent identifies itself and its capabilities to other agents
>
> - authentication: who asserts that an agent has identified itself honestly
>
> - authorization: what data an agent is allowed to ask for, and offer to, other agents; this includes payment schemes for data transfers
>
> - communication: how two agents talk, and whether this conversation has more than two agents
>
> - discovery: how an agent finds out about other agents, their capabilities, and their authorization methods
>
> I'm interested if I missed any major categories, because all of those are also common to database applications, although AI agents very clearly have many different needs in each of them (other than maybe communication).
>
> The reason I based this thread on how AI agents differ from database applications is that the database application world almost never comes to the IETF for protocols after seeing how we did with things like ASID, CRISP, and so on.
>
> --Paul Hoffman
>
> _______________________________________________
> agent2agent mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> agent2agent mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
> --
> WIMSE mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> agent2agent mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> agent2agent mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]