A security architect at an enterprise that has done the work, set up its agent inventory, classified the data connections, and tagged the owners, sits down to review it for the first time. The list is fourteen hundred agents long and counting. Some are clearly business critical. Some are experiments built by a single user that have been running for months. Some touch sensitive data. Some touch sensitive data and can also send email externally. The architect's first question is not what any tool was built to answer. It is: which of these matter, and what am I actually governing when I say I am governing them.
That question marks the boundary between Gen 1 and Gen 2 agentic security.
Gen 1 treated the agent as another path to data. You secured the path the way you secured every other access path: through permissions, through DLP, through identity controls applied to the human invoking the agent. That model still produces useful signal at small scale, when an enterprise has a handful of pilots and a couple hundred users. It collapses at production scale, where the number of agents in a sanctioned AI deployment grows faster than any governance team can keep up with, and where the meaningful unit of risk is not the access path but the agent's behavior across many sessions, many users, and many tools.
Gen 2 starts from a different question. Not "what can this agent reach," which is an access question, but "what is this agent supposed to be doing, and is it doing that." Answering the second question requires an ontology. You cannot govern what you have not described, and the description has to cover more than the agent's permissions. It has to cover what the agent is, what it is supposed to do, what it can reach, how it behaves over time, and who is accountable when it behaves wrong.
Most of the analyst conversations now happening around agentic security converge on a similar set of primitives, even when the vocabulary differs. The clearest way to describe them, mapped to the risks the OWASP Top 10 for Agentic Applications (2026) named in December 2025, is as five elements that together define what governance means in a Gen 2 environment.
Identity. The agent is treated as a first-class identity with a stable, observable profile, not as an attribute of the human invoking it. This is what allows a security team to track an agent across sessions, across users, and across tool calls. Without an agent identity, every invocation looks like a new event, which is why legacy identity tools cannot triangulate agent behavior over time. The non-human identity model is the substrate the rest of the ontology rests on, and it is the operational prerequisite for ASI03 (Identity & Privilege Abuse), which cannot be detected without it.
Intent. A classified description of what the agent is supposed to be doing: the topics it is expected to reason about, the audiences it is expected to serve, and the data domains its purpose justifies it touching. Intent is not a permissions list. A procurement agent and a finance-reporting agent might have overlapping read permissions on a shared data lake; their intents differ. Intent is what makes ASI01 (Agent Goal Hijack) detectable, because a goal hijack manifests as the agent's executed behavior drifting outside its declared intent envelope, while every individual action looks technically authorized.
Scope. The agent's reach across data, tools, and other agents. Scope has two dimensions worth distinguishing. The first is connectivity: which MCP servers, tool calls, data sources, and external services the agent can invoke. The second is autonomy: how much latitude the agent has to seek alternative paths when its first approach to a task does not work. An agent that can rephrase its query, swap tools, or chain into another agent to satisfy a request carries a meaningfully different risk profile than one that can only execute a predefined sequence. ASI02 (Tool Misuse) lives in the first dimension. ASI07 (Insecure Inter-Agent Communication) and ASI08 (Cascading Failures) live in the second.
Behavior. What the agent is actually doing across its history of invocations, measured against the intent it was provisioned with. Behavior is a longitudinal signal, not a per-call signal. It is the difference between "did this single response leak something" and "is this agent's pattern of access drifting in a direction that suggests compromise, misalignment, or simply that someone built it wrong." Behavior is the lens through which ASI10 (Rogue Agents) becomes detectable, because a rogue agent is, by definition, one whose behavior has diverged from its purpose, whether through goal drift, prompt injection that accumulated across sessions, or memory poisoning under ASI06.
Owner accountability. A named human (and ideally, a named team) responsible for what each agent does and for fixing it when it drifts. This sounds like an organizational concern, but it is a technical primitive in disguise, because without an owner mapping, no remediation path closes. A flagged agent with no clear owner becomes a ticket that ages out. The agents that proliferate fastest in real enterprises (the ones built by individual users in business units that did not loop in security) are the ones most likely to have this field empty. Owner accountability is the social layer that turns the other four elements into a working governance program.
The most common failure mode in early agent security programs is not the absence of controls. It is the absence of an ontology those controls can plug into. Teams instrument tooling for sensitive-data exposure, then separately instrument something for destructive actions, then separately instrument something for inter-agent traffic, then end up with three dashboards that cannot be reconciled because each is measuring a different thing about a different concept of the agent.
There is no single primary approach yet. What is becoming clear is that the foundational layer, regardless of which bet a security team makes on instrumentation, has to be a consistent description of the thing being governed. Identity, intent, scope, behavior, owner. If those five elements are described consistently across an enterprise's agent estate, the controls layered on top can be swapped, extended, or replaced without losing the program. If they are not, every new control creates a new silo.
This is also why the question of which sanctioned AI platform an enterprise is running on matters less than it appears to. At Opsin, across our enterprise customer base, we are seeing some shift in where AI adoption is concentrating, with Claude gaining ground inside organizations that previously defaulted to Microsoft Copilot, and ChatGPT Enterprise expanding alongside both. The surface is moving. The ontology, if it is built right, does not have to. An agent governance program anchored in identity, intent, scope, behavior, and ownership applies to a Copilot Studio agent, a custom GPT, a Claude project, or an agent built on a platform like UiPath. The platform is the substrate. The ontology is what makes the governance portable.
Two practical things change for security teams that work from a Gen 2 ontology rather than a Gen 1 access-control posture.
The first is prioritization. An inventory of fourteen hundred agents is not actionable. An inventory of fourteen hundred agents, of which seventy are classified as touching sensitive data, of which eleven are also capable of external output, of which three are showing behavior that drifts from their declared intent, is actionable. The ontology is what turns volume into signal. In customer environments we work in, the share of agents that surface as material risk after this kind of classification typically falls in the low single-digit percentages of the total inventory. Everything else is noise, and treating it as such is what makes the program survivable.
The second is remediation. A Gen 1 incident gets remediated at the symptom: a bad Copilot response gets blocked, a user gets a warning, an alert gets closed. A Gen 2 incident gets remediated at the root cause, because the ontology makes the cause visible. An over-permissioned SharePoint site, a tool grant that did not restrict to the user's credential, an agent shared company-wide that should have been scoped to a department. These are upstream fixes, and they prevent every future invocation that would have exploited the same misconfiguration. Remediation only scales when the ontology makes the upstream visible.
The question to bring to the table is not whether your team has an agent inventory. Many enterprises now do, in some form. The question is whether the inventory describes each agent along the five elements above, and whether anything in your stack produces the deviation signal that makes the description operational.
Without identity, you cannot track an agent across sessions. Without intent, you cannot detect goal hijack. Without scope, you cannot assess blast radius. Without behavior, you cannot find a rogue agent. Without owner accountability, you cannot remediate anything. Gen 1 controls answered the access question. Gen 2 governance answers the behavior question, and the ontology is what makes that answer something a security team can actually run.
A security architect at an enterprise that has done the work, set up its agent inventory, classified the data connections, and tagged the owners, sits down to review it for the first time. The list is fourteen hundred agents long and counting. Some are clearly business critical. Some are experiments built by a single user that have been running for months. Some touch sensitive data. Some touch sensitive data and can also send email externally. The architect's first question is not what any tool was built to answer. It is: which of these matter, and what am I actually governing when I say I am governing them.
That question marks the boundary between Gen 1 and Gen 2 agentic security.
Gen 1 treated the agent as another path to data. You secured the path the way you secured every other access path: through permissions, through DLP, through identity controls applied to the human invoking the agent. That model still produces useful signal at small scale, when an enterprise has a handful of pilots and a couple hundred users. It collapses at production scale, where the number of agents in a sanctioned AI deployment grows faster than any governance team can keep up with, and where the meaningful unit of risk is not the access path but the agent's behavior across many sessions, many users, and many tools.
Gen 2 starts from a different question. Not "what can this agent reach," which is an access question, but "what is this agent supposed to be doing, and is it doing that." Answering the second question requires an ontology. You cannot govern what you have not described, and the description has to cover more than the agent's permissions. It has to cover what the agent is, what it is supposed to do, what it can reach, how it behaves over time, and who is accountable when it behaves wrong.
Most of the analyst conversations now happening around agentic security converge on a similar set of primitives, even when the vocabulary differs. The clearest way to describe them, mapped to the risks the OWASP Top 10 for Agentic Applications (2026) named in December 2025, is as five elements that together define what governance means in a Gen 2 environment.
Identity. The agent is treated as a first-class identity with a stable, observable profile, not as an attribute of the human invoking it. This is what allows a security team to track an agent across sessions, across users, and across tool calls. Without an agent identity, every invocation looks like a new event, which is why legacy identity tools cannot triangulate agent behavior over time. The non-human identity model is the substrate the rest of the ontology rests on, and it is the operational prerequisite for ASI03 (Identity & Privilege Abuse), which cannot be detected without it.
Intent. A classified description of what the agent is supposed to be doing: the topics it is expected to reason about, the audiences it is expected to serve, and the data domains its purpose justifies it touching. Intent is not a permissions list. A procurement agent and a finance-reporting agent might have overlapping read permissions on a shared data lake; their intents differ. Intent is what makes ASI01 (Agent Goal Hijack) detectable, because a goal hijack manifests as the agent's executed behavior drifting outside its declared intent envelope, while every individual action looks technically authorized.
Scope. The agent's reach across data, tools, and other agents. Scope has two dimensions worth distinguishing. The first is connectivity: which MCP servers, tool calls, data sources, and external services the agent can invoke. The second is autonomy: how much latitude the agent has to seek alternative paths when its first approach to a task does not work. An agent that can rephrase its query, swap tools, or chain into another agent to satisfy a request carries a meaningfully different risk profile than one that can only execute a predefined sequence. ASI02 (Tool Misuse) lives in the first dimension. ASI07 (Insecure Inter-Agent Communication) and ASI08 (Cascading Failures) live in the second.
Behavior. What the agent is actually doing across its history of invocations, measured against the intent it was provisioned with. Behavior is a longitudinal signal, not a per-call signal. It is the difference between "did this single response leak something" and "is this agent's pattern of access drifting in a direction that suggests compromise, misalignment, or simply that someone built it wrong." Behavior is the lens through which ASI10 (Rogue Agents) becomes detectable, because a rogue agent is, by definition, one whose behavior has diverged from its purpose, whether through goal drift, prompt injection that accumulated across sessions, or memory poisoning under ASI06.
Owner accountability. A named human (and ideally, a named team) responsible for what each agent does and for fixing it when it drifts. This sounds like an organizational concern, but it is a technical primitive in disguise, because without an owner mapping, no remediation path closes. A flagged agent with no clear owner becomes a ticket that ages out. The agents that proliferate fastest in real enterprises (the ones built by individual users in business units that did not loop in security) are the ones most likely to have this field empty. Owner accountability is the social layer that turns the other four elements into a working governance program.
The most common failure mode in early agent security programs is not the absence of controls. It is the absence of an ontology those controls can plug into. Teams instrument tooling for sensitive-data exposure, then separately instrument something for destructive actions, then separately instrument something for inter-agent traffic, then end up with three dashboards that cannot be reconciled because each is measuring a different thing about a different concept of the agent.
There is no single primary approach yet. What is becoming clear is that the foundational layer, regardless of which bet a security team makes on instrumentation, has to be a consistent description of the thing being governed. Identity, intent, scope, behavior, owner. If those five elements are described consistently across an enterprise's agent estate, the controls layered on top can be swapped, extended, or replaced without losing the program. If they are not, every new control creates a new silo.
This is also why the question of which sanctioned AI platform an enterprise is running on matters less than it appears to. At Opsin, across our enterprise customer base, we are seeing some shift in where AI adoption is concentrating, with Claude gaining ground inside organizations that previously defaulted to Microsoft Copilot, and ChatGPT Enterprise expanding alongside both. The surface is moving. The ontology, if it is built right, does not have to. An agent governance program anchored in identity, intent, scope, behavior, and ownership applies to a Copilot Studio agent, a custom GPT, a Claude project, or an agent built on a platform like UiPath. The platform is the substrate. The ontology is what makes the governance portable.
Two practical things change for security teams that work from a Gen 2 ontology rather than a Gen 1 access-control posture.
The first is prioritization. An inventory of fourteen hundred agents is not actionable. An inventory of fourteen hundred agents, of which seventy are classified as touching sensitive data, of which eleven are also capable of external output, of which three are showing behavior that drifts from their declared intent, is actionable. The ontology is what turns volume into signal. In customer environments we work in, the share of agents that surface as material risk after this kind of classification typically falls in the low single-digit percentages of the total inventory. Everything else is noise, and treating it as such is what makes the program survivable.
The second is remediation. A Gen 1 incident gets remediated at the symptom: a bad Copilot response gets blocked, a user gets a warning, an alert gets closed. A Gen 2 incident gets remediated at the root cause, because the ontology makes the cause visible. An over-permissioned SharePoint site, a tool grant that did not restrict to the user's credential, an agent shared company-wide that should have been scoped to a department. These are upstream fixes, and they prevent every future invocation that would have exploited the same misconfiguration. Remediation only scales when the ontology makes the upstream visible.
The question to bring to the table is not whether your team has an agent inventory. Many enterprises now do, in some form. The question is whether the inventory describes each agent along the five elements above, and whether anything in your stack produces the deviation signal that makes the description operational.
Without identity, you cannot track an agent across sessions. Without intent, you cannot detect goal hijack. Without scope, you cannot assess blast radius. Without behavior, you cannot find a rogue agent. Without owner accountability, you cannot remediate anything. Gen 1 controls answered the access question. Gen 2 governance answers the behavior question, and the ontology is what makes that answer something a security team can actually run.
