Security teams already apply this context to human workforce users. A finance analyst with access to finance systems may be appropriate. A marketing contractor with the same access probably needs review. The permission only makes sense in context.
Agents need the same treatment.
An incident response agent used by site reliability engineers may reasonably need access to observability tools, ticketing systems, runbooks, and even limited remediation actions. The same capabilities on a public support bot would be a serious issue. A finance forecasting assistant may need read access to planning spreadsheets. It probably does not need the ability to email those spreadsheets externally or refresh production reporting datasets.
The permission is not the whole finding. The misalignment between what the agent is meant to do and what it can actually do is the finding.
This is why generic “risky tool” detection quickly becomes noisy. A file deletion, external email, CRM record update, or ticketing automation may be legitimate in one agent and excessive in another. Without intent, security tools can only say, “This agent has a high-impact capability.” They cannot say whether the capability belongs there.
Runtime controls answer an important question: is the agent’s behavior in the moment aligned with the user’s request, the agent’s purpose, enterprise policy, and the context it is acting on?
That view matters. Agents can be manipulated through prompt injection, poisoned context, compromised tools, or ambiguous instructions. A control that checks the action in the moment can catch a harmful step before it completes.
But runtime alignment is a behavior question. Agent posture needs a configuration question: was this agent set up appropriately before it ever ran?
If an HR policy assistant is org-wide and only reads approved HR documents, its surface may match its purpose. If the same assistant can delete files, send external email, or write in broad collaboration spaces, the issue already exists in the design. The agent’s configuration exceeds the work it was meant to do.
Waiting for runtime deviation means waiting until the agent is in motion. Intent alignment should also be part of design-time and posture review.
A useful way to reason about agent risk is to separate two profiles: agent intent and agent scope.
Agent intent alignment sits between several existing control planes.
Identity security can show who owns an agent, what credentials it uses, and what resources it can reach. Application security can test agentic workflows for prompt injection, unsafe tool execution, insecure memory, and related design flaws. OWASP’s Top 10 for Agentic Applications and OWASP’s MCP guidance are useful references for those failure modes, especially when agents can use real identities, access data, invoke tools, or depend on external context.
AI governance frameworks also matter. NIST's AI Risk Management Framework helps organizations define policies, map risks, measure controls, and manage AI systems over time.
All of those layers are useful, but they do not fully answer the posture question by themselves.
The missing layer is proportionality: given what this agent is meant to do, are its audience, data, tools, actions, auth mode, and autonomy justified?
That question is not just a policy question. It is operationally testable.
A practical intent review should be simple enough for agent owners to answer. It can start with five questions:
From there, the agent can be assessed against its actual configuration.
For example, a meeting summary assistant may justify calendar read access and transcript summarization. It may justify drafting an email for human review. It probably should not silently send external emails, create forwarding rules, delete events, or call arbitrary HTTP endpoints unless those actions are explicitly part of its purpose and governed with confirmation or review.
A customer support agent may justify ticket lookup and response drafting. It may not justify internal finance data, source code repositories, or broad org-wide sharing.
Agent inventory should not stop at name, owner, platform, and permissions. For each meaningful agent, security teams should capture:
This creates better findings. Instead of “agent has email tool,” the finding becomes “org-wide HR policy assistant can send external email, but its declared purpose is read-only policy Q&A.” Instead of “agent has sensitive data,” the finding becomes “training assistant has employee medical data attached, which is outside its topic scope.”
That language gives owners something they can fix.
This is the posture layer Opsin sees as necessary for enterprise AI agents: an inventory that not only lists agents and connectors but also explains whether each agent's audience, data, tools, actions, auth mode, autonomy, and ownership make sense for its purpose. That baseline helps teams review agent risk before runtime behavior becomes the only signal.
Agent intent is the purpose an AI agent appears designed to serve. It includes what the agent is meant to do, who it serves, what data it should use, what actions it should take, and what level of autonomy is justified.
Pre-runtime intent review helps security teams catch risky configuration choices before the agent acts. A tool, data source, or sharing setting can be excessive even if the agent has not yet misbehaved.
Agent intent describes what the agent is meant to do. Agent scope describes what the agent can actually reach or do, including connected data, tools, actions, auth context, sharing, channels, autonomy, and delegation paths.
They should compare the agent's intended purpose against its agent scope, including connected data, tools, actions, auth context, sharing scope, channels, autonomy, and delegation paths.
An intent mismatch happens when an agent's scope exceeds its purpose. For example, a read-only HR policy assistant with external email sending, file deletion, or broad write access has an agent scope that does not match its job.
Intent alignment gives teams clearer findings and better remediation paths. Instead of labeling an agent as risky because it has a high-impact capability, the review explains which capability is excessive, unrelated, or unjustified for the agent's purpose.
Security teams already apply this context to human workforce users. A finance analyst with access to finance systems may be appropriate. A marketing contractor with the same access probably needs review. The permission only makes sense in context.
Agents need the same treatment.
An incident response agent used by site reliability engineers may reasonably need access to observability tools, ticketing systems, runbooks, and even limited remediation actions. The same capabilities on a public support bot would be a serious issue. A finance forecasting assistant may need read access to planning spreadsheets. It probably does not need the ability to email those spreadsheets externally or refresh production reporting datasets.
The permission is not the whole finding. The misalignment between what the agent is meant to do and what it can actually do is the finding.
This is why generic “risky tool” detection quickly becomes noisy. A file deletion, external email, CRM record update, or ticketing automation may be legitimate in one agent and excessive in another. Without intent, security tools can only say, “This agent has a high-impact capability.” They cannot say whether the capability belongs there.
Runtime controls answer an important question: is the agent’s behavior in the moment aligned with the user’s request, the agent’s purpose, enterprise policy, and the context it is acting on?
That view matters. Agents can be manipulated through prompt injection, poisoned context, compromised tools, or ambiguous instructions. A control that checks the action in the moment can catch a harmful step before it completes.
But runtime alignment is a behavior question. Agent posture needs a configuration question: was this agent set up appropriately before it ever ran?
If an HR policy assistant is org-wide and only reads approved HR documents, its surface may match its purpose. If the same assistant can delete files, send external email, or write in broad collaboration spaces, the issue already exists in the design. The agent’s configuration exceeds the work it was meant to do.
Waiting for runtime deviation means waiting until the agent is in motion. Intent alignment should also be part of design-time and posture review.
A useful way to reason about agent risk is to separate two profiles: agent intent and agent scope.
Agent intent alignment sits between several existing control planes.
Identity security can show who owns an agent, what credentials it uses, and what resources it can reach. Application security can test agentic workflows for prompt injection, unsafe tool execution, insecure memory, and related design flaws. OWASP’s Top 10 for Agentic Applications and OWASP’s MCP guidance are useful references for those failure modes, especially when agents can use real identities, access data, invoke tools, or depend on external context.
AI governance frameworks also matter. NIST's AI Risk Management Framework helps organizations define policies, map risks, measure controls, and manage AI systems over time.
All of those layers are useful, but they do not fully answer the posture question by themselves.
The missing layer is proportionality: given what this agent is meant to do, are its audience, data, tools, actions, auth mode, and autonomy justified?
That question is not just a policy question. It is operationally testable.
A practical intent review should be simple enough for agent owners to answer. It can start with five questions:
From there, the agent can be assessed against its actual configuration.
For example, a meeting summary assistant may justify calendar read access and transcript summarization. It may justify drafting an email for human review. It probably should not silently send external emails, create forwarding rules, delete events, or call arbitrary HTTP endpoints unless those actions are explicitly part of its purpose and governed with confirmation or review.
A customer support agent may justify ticket lookup and response drafting. It may not justify internal finance data, source code repositories, or broad org-wide sharing.
Agent inventory should not stop at name, owner, platform, and permissions. For each meaningful agent, security teams should capture:
This creates better findings. Instead of “agent has email tool,” the finding becomes “org-wide HR policy assistant can send external email, but its declared purpose is read-only policy Q&A.” Instead of “agent has sensitive data,” the finding becomes “training assistant has employee medical data attached, which is outside its topic scope.”
That language gives owners something they can fix.
This is the posture layer Opsin sees as necessary for enterprise AI agents: an inventory that not only lists agents and connectors but also explains whether each agent's audience, data, tools, actions, auth mode, autonomy, and ownership make sense for its purpose. That baseline helps teams review agent risk before runtime behavior becomes the only signal.
