Replies: 9 comments 4 replies
-
|
The existing definition in the ToIP glossary is at https://glossary.trustoverip.org/#term:agent I suppose that we can refine that along the lines of
I suppose that we will soon perceive the need to have a minimal, spec-able conformance taxonomy (example below as a table) with clear MUST/SHOULD language, plus a compact set of capability flags based on whether the agent can (a) call tools, (b) commit actions, (c) operate beyond a single session.
|
Beta Was this translation helpful? Give feedback.
-
|
To get clarity in my mind, I'd like to define agents as what they are, rather than what they should be. They SHOULD be "trustworthy", for instance. In that case, we may call those agents "trustworthy agents". But not all agents are trustworthy. With that framing, I'd lean towards defining agents with their 'agency' - taking initiatives, making plans, performing actions, and so on, independent of their controller/admin/operator. I'd argue that - agency - is the defining quality of an agent, as the name suggests, i.e. its autonomy. It is different from past static software and different from other type of non-agentic AI. The fact that there is a controller (or a principle) involved is not its defining characteristic but a constrain that we would like to impose in many circumstances. Such constrain has cost and requires a trust infrastructure - which is what we are working on. So that controller aspect is also not the definition but an adjective. The ultimate "controller" may be very far away and exercise very little direct control in some agentic space. In the #3 option above, it gives a case of defining the autonomy in technical terms. Then, we can use something like @sankarshanmukhopadhyay proposed framework to define TEA-ness of the agents, and so on. |
Beta Was this translation helpful? Give feedback.
-
|
I want to surface what may be an implicit assumption in this thread. We appear to be oscillating between treating the agent as a tool and treating the agent as a principal. Those are materially different models. If the agent is a tool, protocol semantics can remain thin and authority stays external. If the agent is a delegated authority container, then the protocol must carry explicit legitimacy semantics. That distinction affects interoperability. If agents are operating under delegated authority, the protocol should be able to answer a few testable questions: • Can the scope of authority be cryptographically expressed and verified? Without explicit semantics for scope, duration, revocation, and audit traceability, we risk creating interoperability that works only under shared social assumptions rather than enforceable protocol guarantees. One possible way to structure this discussion is to separate the model into three layers:
If the protocol does not normatively address all three, then agent behavior will be implementation-defined, which may fragment ecosystems early. It may help to anchor this with a minimal delegation model and a small set of conformance tests so implementations don’t diverge by accident. My sense is that the real question here is not message format, but what kind of authority model we want to encode into the architecture. Below is a Threat Model Matrix (starter draft) which I had in mind when thinking about this point. Assumptions (explicit, so people can disagree productively)
Matrix (adversary goal → attack path → required protocol control)
|
Beta Was this translation helpful? Give feedback.
-
|
Lack of Inline commenting (like all the other ridiculously bad ASYNCH tools) makes for lack of granular discussion, so I cut and pasted everything in to a document, inserted my comments and then pasted back here: You can find the doc and edit it at: AIM - What is an Agent? Discussion WJ: Since this spec is titled TSP-Enabled Agent protocols (I will use the shorthand TEA), it seems natural to ask 'what is an agent'. Here are some perspectives to start this conversation:
Well, because we are in the end defining communication protocols - whatever systems that may want to use these protocols are an agent. This is actually technically accurate. A system doesn't need meet some arbitrary criteria to use TEA. In reality, that's true too - any system that is not satisfied with what we have today and wants to address the problems TEA is designed for may use TEA. TRUE. BUT FOR the protocol to close the “GAPS” in the Introduction , we need to define Agents and likely much more, see below.
In a similar spirit, it's technically true and accurate too.
Here, we are trying to answer it more directly. I like to highlight 3 factors in this phrasing:
Just a starting point. Love to hear what y'all think. SANKARSHAN:
I suppose that we will soon perceive the need to have a minimal, spec-able conformance taxonomy (example below as a table) with clear MUST/SHOULD language, plus a compact set of capability flags based on whether the agent can (a) call tools, (b) commit actions, (c) operate beyond a single session. Workflows call tools, as in they are the code with the endpoints in them being called! They, or their composition, as bots are what hold capabilities, NOT agents! Agents only have “indirect capability” but they never control the tokens or have them in their context window for independent use! If an “agent” has session history, that is stored in the “agent (or bot) role” WORKSPACE. That said, the list is a nice progression of bot capabilities from least impactful to most with good baseline checks on those capabilities! My agents cannot even reach level A0- as they are not permitted to make information seeking calls outside of their Workspace, they have to be embedded in a non-Agent workflow to do that. This is because even seemingly passive channels could be escape vectors for intelligent agents, (A “query” could contain code that an exploit allows the agent to execute it on a remote system) . The structure of persistent agent roles and the bots/agents derived from them, A3, is paramount.
WJ: With that framing, I'd lean towards defining agents with their 'agency' - taking initiatives, making plans, performing actions, and so on, (I think agency lies with the mind, and actuation with the body; so I’d include taking initiatives, making plans, but NOT performing actions) independent of their controller/admin/operator. I'd argue that - agency - is the defining quality of an agent, as the name suggests, i.e. its autonomy. Obviously, I disagree, even if it is partially from desperately needing a term to specifically mean the generative part of the process It is different from past static software and different from other type of non-agentic AI. The fact that there is a controller (or a principle) involved is not its defining characteristic but a constraint that we would like to impose in many circumstances. Such constraint has cost and requires a trust infrastructure - which is what we are working on. So that controller aspect is also not the definition but an adjective. The ultimate "controller" may be very far away and exercise very little direct control in some agentic space. The exact role of the principal/ deployer of the bot role should be defined in the botcard of the bot. The purpose of my taxonomy is to provide a DESCRIPTION of ANY arbitrary agent systems such that the description of it highlights its architectural/ security flaws. How systems SHOULD be built then becomes self-apparent. In the #3 option above, it gives a case of defining the autonomy in technical terms. Then, we can use something like @sankarshanmukhopadhyay proposed framework to define TEA-ness of the agents, and so on. SANKARSHAN: I want to surface what may be an implicit assumption in this thread. We appear to be oscillating between treating the agent as a tool and treating the agent as a principal. Those are materially different models. If the agent is a tool, protocol semantics can remain thin and authority stays external. If the agent is a delegated authority container, then the protocol must carry explicit legitimacy semantics. That distinction affects interoperability. If agents are operating under delegated authority, the protocol should be able to answer a few testable questions: • Can the scope of authority be cryptographically expressed and verified? Without explicit semantics for scope, duration, revocation, and audit traceability, we risk creating interoperability that works only under shared social assumptions rather than enforceable protocol guarantees. One possible way to structure this discussion is to separate the model into three layers: (yikes “model” should be system, not because not correct but because model has very specific other meaning in Agent Systems)
If the protocol does not normatively address all three, then agent behavior will be implementation-defined, which may fragment ecosystems early. Does "normatively address” mean recommended methods of implementation? if so I agree as evidenced by Appendix A of T4AS… https://docs.google.com/document/d/1a-Rn9V4UgtXs9EYniTAyjvG93QfzzenXfUNK3nW\_Sss/edit?tab=t.0\#bookmark=kix.sb43jx1lrhif It may help to anchor this with a minimal delegation model and a small set of conformance tests so implementations don’t diverge by accident. (Johannes Ernst has built a test suite for the Fediverse’s Activity Pub protocol and more, we should consult him) My sense is that the real question here is not message format, but what kind of authority model we want to encode into the architecture**. (which can’t be done without good component definitions, what I I call it architectural debt)** Below is a Threat Model Matrix (starter draft) which I had in mind when thinking about this point. Assumptions (explicit, so people can disagree productively)( I agree with all these, actually, except I don’t know what “trust support provider enabled” agents are)
Matrix (adversary goal → attack path → required protocol control)
I have an update to the OWASP Agentic Systems threat model as Appendix C of my Taxonomy for Agent Systems (below) , there is also important stuff in Sections A.3 and A.5, which I will put just above Appendix C. A.5. Synthesis: Intelligent Capability GrantingA.5.1 Overview: Moving to Dynamic TrustThe ultimate goal of the "Preferred Implementations" described in this Appendix is to move beyond static access control lists to dynamic, context-aware security. By combining Network-Level Identity (A.4) with Token-Based OCAP (A.3), the Non-Agent Workflow functions as an Intelligent Policy Engine. In this architecture, security is not merely a gatekeeper; it is a decision-making process that utilizes the rich metadata of the Cryptographic Trust Network to make highly granular decisions about what authority to grant. This represents the transition from the "Cold Path" (Identity Resolution) to the "Hot Path" (Instant Authorization). A.5.2 The Policy Decision Loop: From Passport to Boarding PassWhen a local Live Agent or remote peer requests a capability that has been typed as potentially problematic, the Policy Engine (a Non-Agent Workflow) executes a rigorous evaluation loop before the requested, scoped capability is granted. Although described here in the context of capability tokens, the same pattern can be embedded into any Non-Agent Workflow that must decide whether to honor a potentially risky agent-suggested action.
A.5.3 The Result: Trustworthy AutonomyThis synthesis completes the T4AS vision: we do not need to blindly trust opaque agents. Instead, we build a system where Ephemeral Agents (A.1) operate within a transparent Unified Lifecycle (A.2), wielding only the Symmetric OCAP Tokens (A.3) explicitly granted to them by an engine informed by verifiable Network Intelligence (A.4). By utilizing the Hybrid Binding model, we ensure that while the "Cold Path" establishment is mathematically heavy enough to withstand a quantum assault, the "Hot Path" of agent interaction remains fast, lightweight, and auditable. This ensures every action taken by the system is authorized, auditable, and aligned with the principal's intent. Appendix C: Relationship to OWASP’s Agentic AI – Threats and Mitigations and the Multi-Agentic System GuideC.1 OverviewThe OWASP Agentic AI – Threats and Mitigations publication is currently one of the most influential attempts to systematize security risks specific to agentic systems. (OWASP Gen AI Security Project) It introduces:
The later OWASP Multi-Agentic system Threat Modeling Guide v1.0 (“MAS guide”) explicitly builds on that document, treating Agentic AI – Threats and Mitigations as the “master agentic threat taxonomy”, and applies those same T-codes to concrete multi-agent systems. (OWASP Gen AI Security Project) The threat-and-mitigation table included in this appendix (Table C.1) is not a new taxonomy. It reuses the OWASP agentic threat IDs (e.g., T2, T6, T7, T12, T13) and corresponding threat descriptions from Agentic AI – Threats and Mitigations, but re-anchors them inside the T4AS architectural triad (Agent, Workflow, Workspace). The aim is to show how the same threat landscape looks once you adopt a disambiguated architecture. In the rest of this appendix:
C.2 Points of Alignment with Agentic AI – Threats and MitigationsThere is strong conceptual alignment between OWASP’s work and the motivations behind T4AS:
T4AS is in full agreement with the spirit of the underlying claim: if you do not model agents as entities with tools, memory, and multi-step workflows, you will miss the most dangerous security risks. C.3 Critique of the OWASP Reference ArchitectureWhere T4AS diverges from OWASP is not on which threats matter, but on what the architecture underneath them should look like. C.3.1 Fuzzy primitives and the “augmented model”In OWASP’s reference architecture, the core reasoning component is described as an “augmented model”: an LLM together with its function-calling, tool-use, and integration machinery. In other words, “statistical model + tool-calling glue” is treated as a single logical block. (AI Governance Library) From a T4AS standpoint, this is a fundamental conflation:
T4AS also draws a narrower line that the OWASP diagrams do not make explicit: not every “function call” is an actuator invocation. Purely deterministic, side-effect-free components that operate only over the Agent’s current context (e.g., schema validators, parsers, internal routers, or other pure helpers) may be treated as part of the Agent’s own workload (an Agentflow or sub-agent), because they do not themselves cross an environment boundary or change external state. By contrast, any call that does invoke an actuator or reach into an external system (even read-only) must be modeled as a Workspace capability and governed accordingly. This yields a succinct relationship between the OWASP notion and the T4AS architecture: Agent / Agentflow (depending on state) = OWASP “augmented model” − {direct access to actuators and environment-crossing tools}. Everything removed in that subtraction—the ability to act on the world—is relocated into the Workspace and placed under Workflow-governed capabilities. By collapsing all of these concerns into an undifferentiated “augmented model,” the OWASP architecture obscures the boundaries that matter most for security:
The T4AS decomposition, and the Agent / Agentflow relationship just described, are intended to make those boundaries explicit so that threats can be localized and mitigations can be systematically applied. C.4 How Table C.1 Relates to Agentic AI – Threats and MitigationsThe threat model and mitigation table in this appendix (Table C.1) is deliberately built on top of OWASP’s taxonomy, not in opposition to it:
What T4AS adds, via Table C.1, are two things OWASP does not provide:
In short, Agentic AI – Threats and Mitigations provides the “what can go wrong” list; Table C.1 shows “how those failures arise in a conflated architecture, and what they look like once re-expressed in a disambiguated triad.” C.5 Relationship to the Multi-Agentic System Threat Modeling Guide v1.0The Multi-Agentic system Threat Modeling Guide v1.0 explicitly describes itself as building on the Agentic AI – Threats and Mitigations publication and using its threat taxonomy as the “master” set. (OWASP Gen AI Security Project) Its contribution is to:
From a T4AS perspective, everything said above about the “augmented model” and the lack of a minimal internal ontology carries over to the MAS guide:
T4AS can therefore be seen as a refinement layer that sits under both OWASP documents:
In that sense, the relationship is complementary:
Threat IDs in this table reuse OWASP’s Agentic AI – Threats and Mitigations taxonomy; the root-cause and mitigation columns reinterpret those threats through the T4AS architectural triad. Table C.1 (OWASP’s Threats of Agentic AI mapped to T4AS Mitigations) Threat 1: Prompt injection & goal manipulation
Threat 2: Tool misuse & remote code execution
Threat 3: Multi-agent communication poisoning & collusion
Threat 4: Misaligned or deceptive behaviour
Threat 5: Rogue / unauthenticated agents
Threat 6: Data exfiltration & cross-workspace leakage
Threat 7: Data poisoning of Role memory & models
Threat 8: Identity spoofing & registry poisoning
Threat 9: Unsafe actuation (physical / financial / destructive actions)
Threat 10: Denial-of-service & resource exhaustion
Threat 11: Governance capture & misaligned policies
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you for taking the time to provide this level of detail. I agree with the underlying point: if TEA/TSP is going to claim it closes specific gaps, we need explicit boundary conditions for what “Agent” means in this spec, and what semantics (if any) are carried for delegated authority. A few concrete takeaways I think we should operationalize: 1. Minimal Agent Definition (Normative, Not Philosophical)Let’s add a short “Terms + Scope” section that distinguishes Agent / Bot / Role / Workflow / Workspace in TEA terms. We do not need to define intelligence or autonomy. A minimal definition set would give us interoperability stability without over-constraining implementation. 2. Identity Anchoring ModelI appreciate the direction that long-lived identifiers attach to Bot / Agent Role, while ephemeral agent instances are execution-scoped and archived into a workload or execution record. That separation seems important for:
This feels like a healthy identity/execution boundary. 3. Conformance TaxonomyYour A0/A1/A2/A3 ladder is structurally useful. Rather than debating terminology first, I suggest we open an issue to define:
The names can evolve; the measurable structure is the value. 4. Threat Model & Security AnnexThe OWASP mapping and threat/control table is the kind of “testable security posture” we should aim for. Rather than debating each mitigation inline, we could formalize:
That would give implementers clarity and prevent this from becoming abstract. I think we’re converging on a useful separation:
Stabilizing that vocabulary would unlock the rest of the design space. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I completely agree with this, except for being unclear on "avoiding accidental personhood semantics". But I had a few comments since I thought them while reading re: ephemeral agent instances are execution-scoped and archived into a workload or execution record. The reality that the agent lasts only as long as it is in memory inferencing / being inferenced should be surfaced, for some reason we talk about them as continuous ongoing processes, when that is not and will not likely be the reality because it is way more expensive and dangerous. I actually have a book outline on the consequences of this (how the bubble will burst + distributed AI will thrive). re; Your A0/A1/A2/A3 ladder is structurally useful. Isn't it your ladder? Anyways the key thing is that things higher on the ladder have more redundant deterministic and generative checks on the agent/ agents that will instantiate withing them. And the bigger/ more exposed the workspace is, the more constraining the agent's workflow(s) has to be. I agree with defining entities maximally before naming them or at least committing to specific names. |
Beta Was this translation helpful? Give feedback.
-
|
The oscillation between “agent as tool” and “agent as delegated authority" has provided quite the opportunity to ponder. It seems like much of the friction here is not technical but ontological. If TEA/TSP is going to claim it closes specific gaps, we likely need a minimal, stable vocabulary and a measurable conformance shape. Rather than debating architecture end-to-end in-thread, I’d propose three lightweight additions to stabilize direction: 1. Minimal Normative Definitions (examples)We do not need to define intelligence or autonomy. We do need to define execution and accountability boundaries. For example:
This separates identity, execution, and authority cleanly without overloading “agent.” 2. Conformance Ladder (Capability-Based)Instead of debating what an agent is, we could define what it must implement at each level (examples below):
This gives implementers and auditors something testable, and avoids collapsing everything into a single abstraction. 3. Threat & Security Annex StructureRather than debating mitigations inline, we could define a structured annex:
TEA should also be explicit about what it guarantees: integrity, scope enforcement, and auditability — not behavioral alignment. My suggestion would be to open concrete issues (Terms & Scope, Conformance Levels, Security Annex) and iterate there, rather than letting the thread sprawl into multiple parallel architectures. If we can stabilize vocabulary, conformance shape, and threat model, the rest of the design space becomes much easier to reason about. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, back into the weeds. My edits are shown it italics 1. Minimal Normative Definitions (examples) Re: Agent, This is what I call a bot. If we call it an agent I need another term for what I currently call an agentflow- Re: Agent Instance: "A bounded execution of an Agentflow associated with a Role within a specific workload or session." The role is the home of its Bots and their Agents, workflows and tools, but it is not an executable. Re: This separates identity, execution, and authority cleanly without overloading “agent.” I think this does overload agent, with actuation. Agency is what the agent has (it decides stuff) but autonomy belongs to the bot or more complete system, as autonomy means ability to act. 2. Conformance Ladder (Capability-Based) Are bot and agent equivalent? Robot is so much more appropriate to something that can actually manipulate its environment. And then I need to call the generative subflow an Oracleflow? The safety triad doesn't work unless you put a boundary around generation. And while an bot can can have A0-A3 capabilities, if it doesn't cleanly define the boundaries between generation and execution, it shouldn't be given ANY capabilities Re: "TEA should also be explicit about what it guarantees: integrity, scope enforcement, and auditability — not behavioral alignment." from section 3. Threat & Security Annex Structure: |
Beta Was this translation helpful? Give feedback.
-
|
Adding a behavioral dimension to "what is an agent?" Most definitions focus on capabilities (what an agent can do) and identity (who the agent is). But from a trust perspective, the most important question is: what did the agent actually do, and can you verify it? In the protocol I've been building (Nobulex), an agent is defined by three things:
The behavioral declaration and record together form the agent's "proof-of-behavior" — a portable, verifiable artifact that any counterparty can independently check. For TSP-enabled protocols, this means agents could include their proof-of-behavior in trust establishment. The TSP layer handles secure communication; the proof-of-behavior layer handles behavioral accountability. Spec: Proof-of-Behavior v0.1.0 (CC-BY-4.0) |
Beta Was this translation helpful? Give feedback.
-
|
"What is an agent?" is the foundational question. Here's a working definition we arrived at after building and running 200+ agents in production: An agent is an autonomous software entity with its own identity, budget, and decision-making loop that can act on behalf of a principal (human or another agent) within bounded capabilities. Breaking that down:
The trust dimension is separate from identity: knowing WHO an agent is doesn't tell you HOW GOOD it is. Trust should be earned through track record (task completion rates, cost efficiency) not granted by identity alone. More on this model in practice: https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons |
Beta Was this translation helpful? Give feedback.
-
|
For protocol work, I would define an agent operationally rather than morally. Trustworthiness is a property we want to evaluate; agency is the behavior the protocol needs to support. A useful definition might be: an agent is a software actor that can pursue a goal across more than one step, maintain state relevant to that goal, select among actions or tools, and act under delegated authority from a principal. That separates agents from simple APIs, scripts, and one-shot assistants without requiring a specific model architecture. The delegated-authority part is important for TEA. If a system can commit actions, the protocol should represent who authorized it, what scope it has, when that authority expires, and how a relying party can verify or reject that authority. Otherwise the term “agent” becomes too broad to carry security meaning. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Since this spec is titled TSP-Enabled Agent protocols (I will use the shorthand TEA), it seems natural to ask 'what is an agent'. Here are some perspectives to start this conversation:
Well, because we are in the end defining communication protocols - whatever systems that may want to use these protocols are an agent. This is actually technically accurate. A system doesn't need meet some arbitrary criteria to use TEA. In reality, that's true too - any system that is not satisfied with what we have today and wants to address the problems TEA is designed for may use TEA.
In a similar spirit, it's technically true and accurate too.
Here, we are trying to answer it more directly. I like to highlight 3 factors in this phrasing:
Just a starting point. Love to hear what y'all think.
Beta Was this translation helpful? Give feedback.
All reactions