.png)
A CISO I spoke with last week described his worst-case scenario in one sentence: a runaway agent with access to a handful of MCP integrations performs mass data exfiltration or destructive writes faster than any human or existing security tool can intervene. He was working backwards from that scenario, asking a question most enterprise security programs are not yet structured to answer. Does the agent stay within its original design and access boundaries, and what happens when it does not?
That question is what we mean by agent intent. Intent is the declared purpose of an AI agent, expressed through its name, description, system prompt, attached tools, data sources, and the policies governing how it can be invoked. It is the design contract. Everything an agent does in production should be evaluable against it. When the contract and the behavior diverge, that divergence is where enterprise AI risk actually lives.
The first generation of enterprise AI security has been about visibility, knowing which agents exist, who built them, and what they can reach. Visibility is necessary, but also not sufficient. The harder problem is what to do with that visibility, and the answer starts with treating agent intent as a first-class security construct. This article is a working model for how security teams should think about it across two dimensions that are often conflated: posture, which is whether an agent's configuration matches its stated purpose before it runs, and behavior, which is whether its actions stay aligned with that purpose once it does. Both matter. Neither is well served by the tools most security teams already own.
Agent intent is the security-relevant expression of what an AI agent is designed to do. In a Copilot Studio agent, intent is partially encoded in the agent's name and instructions and partially in the tools and actions explicitly attached to it. In Claude Projects, intent is expressed mostly through project instructions, attached files, and sharing scope, while the connectors that determine the effective execution surface may be enabled separately at the organization, user, or conversation level. In ChatGPT Enterprise, intent shows up in custom GPT definitions and the connectors a user can reach. The form varies. The principle does not.
Intent matters because every other control depends on it. You cannot apply least privilege without knowing what privilege the agent is supposed to have. You cannot detect deviation without a baseline of intended behavior. You cannot evaluate whether a prompt injection succeeded without knowing what the agent was supposed to refuse. Identity, data, and model behavior all become interpretable only when anchored to a clear statement of purpose.
This is the gap legacy controls do not close. Endpoint detection and response captures what a human types into a browser. Browser-based AI security extensions capture the same surface. A CISO put this plainly in a recent conversation: at best, those tools capture human input, and the actual problem is what agents do server-side, often through MCP integrations the user never sees.
The question stops being "what did the user prompt" and becomes "what is the agent designed to do, what can it actually reach, and is its current behavior consistent with both."
Intent classification has to work in two modes, and most enterprises will need both.
The first is static classification at deployment or registration time. When an agent is created in Copilot Studio or a project is configured in Claude, its declared purpose can be inferred from its name, description, instructions, attached files, and the tools or connectors associated with it. That inference produces a category, for example a financial document intelligence agent, a support summarization agent, a code review agent. Categorization is what makes template-like controls possible. A financial document intelligence agent should have a defined set of permitted data sources and a defined set of allowed actions. Categorization without controls is theater. Controls without categorization do not scale.
The second is continuous classification as agents evolve. Agents are not static artifacts. Their instructions change, new connectors are enabled at the user or conversation level, and sharing scope expands. An agent that began as a support summarizer can be one configuration change away from a financial data exfiltration vector.
Continuous classification means evaluating the current state of the agent against its declared intent every time something material changes, not just at registration.
The hard part is that the execution surface is not always bound to the agent itself.
In Copilot Studio, tools and actions are typically attached to the agent and travel with it.
In Claude Projects today, the project mostly defines context, instructions, files, and sharing, while connectors are governed at broader scopes. That means a project can look clean in isolation while the effective execution surface, the connectors a user happens to have enabled, is dramatically broader than the project's instructions suggest. Claude's managed agents will likely look more like the agent-bound model, where system prompt, tools, MCP servers, skills, files, and execution environment are explicit parts of the agent configuration. Until that becomes the universal pattern, security teams need to evaluate intent against the full effective surface, not just what the agent owner declared.
Intent deviation is the gap between what an agent is designed to do and what it actually does. It is the execution expression of the same construct that posture evaluates statically with 4 key elements:
Detecting these deviations requires the telemetry to be interpretable against intent. A log line that says an agent called an MCP server is meaningless without context about what the agent was supposed to do, what data the call touched, who invoked it, and whether this pattern is consistent with prior behavior. This is what we mean when we describe Opsin's dynamic contextual layer connecting identity, data, and model behavior. The context is what makes the deviation legible.
Posture and behavior are usually treated as separate domains in enterprise security. For agentic AI, they are two views of the same construct.
Posture analysis evaluates the alignment between an agent's declared intent and its effective execution surface before any user invokes it. An agent whose instructions describe summarizing customer support tickets but whose attached or inheritable connectors include write-capable access to a finance system is misaligned at rest. That misalignment is an issue regardless of whether the agent has ever been invoked maliciously. It is a least-privilege problem. The blast radius is determined long before any prompt is ever entered.
Behavioral analysis evaluates whether an agent's actions, once it is operating, stay consistent with its intent and its posture baseline. The two layers reinforce each other. A posture finding tells you to narrow access before an incident. A behavior finding tells you when an agent has drifted from its intended use after the fact. Together they give security teams a way to reduce blast radius proactively and to surface deviation when reduction was not enough.
For practitioners building toward this, the OWASP GenAI Security Project provides useful anchors. Excessive agency is named explicitly in the OWASP Top 10 for LLM Applications, defined as the risk that an LLM-based system takes damaging actions in response to ambiguous or manipulated input because it has been granted more functionality, permissions, or autonomy than its use case requires. OWASP's recommended mitigation is to limit the tools, functions, and permissions an agent has to the minimum necessary for its intent. That is the least-privilege angle, stated in the standard. The MITRE ATLAS framework catalogs the adversarial techniques that exploit over-privileged agents once they exist. NIST AI RMF, in its Manage function, calls for ongoing assessment of AI system behavior against intended use. The frameworks agree on the principle. The implementation gap is what most enterprises are still working through.
Microsoft Purview and other similar tools approach AI risk through a DLP lens. They are strong at classifying data and at detecting when sensitive content moves in ways that violate policy. They do not natively model agent intent as a foundational starting point. Their unit of analysis is the data object and the user, not the agent and its design contract. Other tools focus on prompt-layer controls, evaluating the input and output of an LLM interaction. That is useful, but it does not capture intent. A prompt can be entirely benign while the agent it invokes has an execution surface its design never intended. Other solutions have built strong capability around low-code platforms and agent governance, particularly in the Microsoft ecosystem.
Opsin connects identity, data, and model behavior across sanctioned enterprise AI deployments, with agent intent at the center. We give security teams the visibility to understand what their agents are designed to do, the posture analysis to flag when configuration drifts from intent, and the behavioral context to surface deviation when it occurs. The remediation lands at the root cause, the misalignment between intent and execution surface, not at the alert.
Most enterprises have agents in production today and could be one configuration change, one new MCP connector, or one inherited permission away from a worst case scenario. The teams getting ahead of this are the ones who have started asking "what is each agent designed to do, what can it actually reach, and how would we know if it stopped behaving consistently with both."
A CISO I spoke with last week described his worst-case scenario in one sentence: a runaway agent with access to a handful of MCP integrations performs mass data exfiltration or destructive writes faster than any human or existing security tool can intervene. He was working backwards from that scenario, asking a question most enterprise security programs are not yet structured to answer. Does the agent stay within its original design and access boundaries, and what happens when it does not?
That question is what we mean by agent intent. Intent is the declared purpose of an AI agent, expressed through its name, description, system prompt, attached tools, data sources, and the policies governing how it can be invoked. It is the design contract. Everything an agent does in production should be evaluable against it. When the contract and the behavior diverge, that divergence is where enterprise AI risk actually lives.
The first generation of enterprise AI security has been about visibility, knowing which agents exist, who built them, and what they can reach. Visibility is necessary, but also not sufficient. The harder problem is what to do with that visibility, and the answer starts with treating agent intent as a first-class security construct. This article is a working model for how security teams should think about it across two dimensions that are often conflated: posture, which is whether an agent's configuration matches its stated purpose before it runs, and behavior, which is whether its actions stay aligned with that purpose once it does. Both matter. Neither is well served by the tools most security teams already own.
Agent intent is the security-relevant expression of what an AI agent is designed to do. In a Copilot Studio agent, intent is partially encoded in the agent's name and instructions and partially in the tools and actions explicitly attached to it. In Claude Projects, intent is expressed mostly through project instructions, attached files, and sharing scope, while the connectors that determine the effective execution surface may be enabled separately at the organization, user, or conversation level. In ChatGPT Enterprise, intent shows up in custom GPT definitions and the connectors a user can reach. The form varies. The principle does not.
Intent matters because every other control depends on it. You cannot apply least privilege without knowing what privilege the agent is supposed to have. You cannot detect deviation without a baseline of intended behavior. You cannot evaluate whether a prompt injection succeeded without knowing what the agent was supposed to refuse. Identity, data, and model behavior all become interpretable only when anchored to a clear statement of purpose.
This is the gap legacy controls do not close. Endpoint detection and response captures what a human types into a browser. Browser-based AI security extensions capture the same surface. A CISO put this plainly in a recent conversation: at best, those tools capture human input, and the actual problem is what agents do server-side, often through MCP integrations the user never sees.
The question stops being "what did the user prompt" and becomes "what is the agent designed to do, what can it actually reach, and is its current behavior consistent with both."
Intent classification has to work in two modes, and most enterprises will need both.
The first is static classification at deployment or registration time. When an agent is created in Copilot Studio or a project is configured in Claude, its declared purpose can be inferred from its name, description, instructions, attached files, and the tools or connectors associated with it. That inference produces a category, for example a financial document intelligence agent, a support summarization agent, a code review agent. Categorization is what makes template-like controls possible. A financial document intelligence agent should have a defined set of permitted data sources and a defined set of allowed actions. Categorization without controls is theater. Controls without categorization do not scale.
The second is continuous classification as agents evolve. Agents are not static artifacts. Their instructions change, new connectors are enabled at the user or conversation level, and sharing scope expands. An agent that began as a support summarizer can be one configuration change away from a financial data exfiltration vector.
Continuous classification means evaluating the current state of the agent against its declared intent every time something material changes, not just at registration.
The hard part is that the execution surface is not always bound to the agent itself.
In Copilot Studio, tools and actions are typically attached to the agent and travel with it.
In Claude Projects today, the project mostly defines context, instructions, files, and sharing, while connectors are governed at broader scopes. That means a project can look clean in isolation while the effective execution surface, the connectors a user happens to have enabled, is dramatically broader than the project's instructions suggest. Claude's managed agents will likely look more like the agent-bound model, where system prompt, tools, MCP servers, skills, files, and execution environment are explicit parts of the agent configuration. Until that becomes the universal pattern, security teams need to evaluate intent against the full effective surface, not just what the agent owner declared.
Intent deviation is the gap between what an agent is designed to do and what it actually does. It is the execution expression of the same construct that posture evaluates statically with 4 key elements:
Detecting these deviations requires the telemetry to be interpretable against intent. A log line that says an agent called an MCP server is meaningless without context about what the agent was supposed to do, what data the call touched, who invoked it, and whether this pattern is consistent with prior behavior. This is what we mean when we describe Opsin's dynamic contextual layer connecting identity, data, and model behavior. The context is what makes the deviation legible.
Posture and behavior are usually treated as separate domains in enterprise security. For agentic AI, they are two views of the same construct.
Posture analysis evaluates the alignment between an agent's declared intent and its effective execution surface before any user invokes it. An agent whose instructions describe summarizing customer support tickets but whose attached or inheritable connectors include write-capable access to a finance system is misaligned at rest. That misalignment is an issue regardless of whether the agent has ever been invoked maliciously. It is a least-privilege problem. The blast radius is determined long before any prompt is ever entered.
Behavioral analysis evaluates whether an agent's actions, once it is operating, stay consistent with its intent and its posture baseline. The two layers reinforce each other. A posture finding tells you to narrow access before an incident. A behavior finding tells you when an agent has drifted from its intended use after the fact. Together they give security teams a way to reduce blast radius proactively and to surface deviation when reduction was not enough.
For practitioners building toward this, the OWASP GenAI Security Project provides useful anchors. Excessive agency is named explicitly in the OWASP Top 10 for LLM Applications, defined as the risk that an LLM-based system takes damaging actions in response to ambiguous or manipulated input because it has been granted more functionality, permissions, or autonomy than its use case requires. OWASP's recommended mitigation is to limit the tools, functions, and permissions an agent has to the minimum necessary for its intent. That is the least-privilege angle, stated in the standard. The MITRE ATLAS framework catalogs the adversarial techniques that exploit over-privileged agents once they exist. NIST AI RMF, in its Manage function, calls for ongoing assessment of AI system behavior against intended use. The frameworks agree on the principle. The implementation gap is what most enterprises are still working through.
Microsoft Purview and other similar tools approach AI risk through a DLP lens. They are strong at classifying data and at detecting when sensitive content moves in ways that violate policy. They do not natively model agent intent as a foundational starting point. Their unit of analysis is the data object and the user, not the agent and its design contract. Other tools focus on prompt-layer controls, evaluating the input and output of an LLM interaction. That is useful, but it does not capture intent. A prompt can be entirely benign while the agent it invokes has an execution surface its design never intended. Other solutions have built strong capability around low-code platforms and agent governance, particularly in the Microsoft ecosystem.
Opsin connects identity, data, and model behavior across sanctioned enterprise AI deployments, with agent intent at the center. We give security teams the visibility to understand what their agents are designed to do, the posture analysis to flag when configuration drifts from intent, and the behavioral context to surface deviation when it occurs. The remediation lands at the root cause, the misalignment between intent and execution surface, not at the alert.
Most enterprises have agents in production today and could be one configuration change, one new MCP connector, or one inherited permission away from a worst case scenario. The teams getting ahead of this are the ones who have started asking "what is each agent designed to do, what can it actually reach, and how would we know if it stopped behaving consistently with both."
.png)
