Feature Update
An HR agent scoped to answer benefits questions on Monday can end up pulling SSNs into a marketing chat by Friday for someone it was never intended to serve, and nothing in its permissions ever changed. The access was always there. What changed was what the agent decided to do with it. A prompt injection, poisoned context, a memory update, or an unexpected tool response can push it into work that no longer matches its original intent. Agent Behavior Baselining is built to catch that.
Today it gets easier to see: drift against intent now renders in the Agent Detail pane, so a security team can trace how an agent's actual behavior tracks its declared purpose over time, not just read a finding after the fact.
A financier isn't a developer, neither is a marketing ops leader, but both are still creating agents that often end up overprivileged. The underlying problem is not that agents get reconfigured carelessly but rather that agents drift into risky work without any configuration changes at all. The identity, the permissions, and the tool list all look exactly the same as they did yesterday. What changed is the action the agent actually took.
That is a hard problem for approaches built purely from historical activity. Watching an agent's behavior over time and flagging deviation from its own history is a reasonable starting point, and it is the model most of the market has converged on. It has a structural weakness: if an agent was provisioned with excessive tools or broad access from the start, historical behavior teaches the monitoring system that the excess is normal. The baseline calibrates to the risk instead of catching it. A statistical baseline also has no independent way to judge whether a given action belongs to the agent in the first place. An incident response agent accessing a database, restarting a service, and opening a ticket is unremarkable. A public support bot doing the same thing deserves immediate review. The action alone does not carry that distinction.
That distinction comes from declared intent. Agent Intent classification separates an agent's posture into distinct dimensions: who it is meant to serve, what topic or data domain it should handle, what action classes it should take, what goal it is pursuing, and which guardrails it declares, all inferred from evidence captured at provisioning time rather than learned from watching the agent run. Agent Behavior Baselining extends that classification forward into observed patterns: tool use, data access, identity mode, workflow sequence, destinations, audience, volume, and timing.
Agents are also supposed to adapt, so alerting on every new path drowns the signal that matters. A finance agent calling a planning spreadsheet more often near month-end is not a finding. A read-only HR policy agent picking up a tool that can send external email is. The stronger signal combines drift with blast radius, the pattern behind what's sometimes called the lethal trifecta of sensitive data, untrusted input, and external reach. The risk shows up in the chain: the action, the data involved, the identity it ran under, the destination, and the agent's declared purpose no longer line up.
When a finding surfaces, the review stays grounded in four questions: what changed, which intent dimension it touches (audience, topic, action, goal, or guardrail), what the agent could reach or change as a result, and whether the behavior still matches the agent's declared purpose.
Agent Behavior Baselining has been running in the Opsin platform, comparing observed agent behavior against declared intent and surfacing findings when the two diverge. What's new is how that comparison shows up for the security team reviewing it.
The Agent Detail pane now shows drift as a direct comparison against declared intent, not a standalone text alert. Each agent's Agent Intent block states its declared purpose and explicitly out-of-scope activity, alongside the sensitive data types and knowledge sources it touches. Below that, Typical Initiators, Typical Topics, and Typical Actions show the intent-aligned baseline side by side with an anomalies column, so a reviewer sees the normal pattern (e.g. HR and Finance users, contract and compliance topics) directly next to what broke from it (a guest or marketing user initiating the agent, a query into executive salary negotiation details). Each anomaly is tied back to the specific intent dimension it violates, so a CISO scanning the pane can tell at a glance which agents drifted, where, and why it matters.
This does not change how the baseline is built. It changes how quickly a reviewer can answer the question the baseline was built to ask: does this agent still behave like the agent it was declared to be?
This feature update extends the same declared-intent anchor already live in the Agent Detail pane, and Opsin is continuing to expand the underlying classification of tools, MCP servers, and data connections each agent can reach.
To learn more about Opsin’s Behavior Baselining, contact your Opsin Customer Success Manager.
Agent behavior baselining is the practice of profiling how an AI agent normally operates across purpose, audience, tools, data access, identity use, workflow sequence, destinations, volume, and timing so meaningful deviations can be reviewed as security signals.
The underlying baselining capability in Opsin was already live. This update now shows drift as a direct comparison against declared intent in the Agent Detail pane, so security teams can see observed behavior against declared intent instead of reviewing drift findings as text alone.
Agent Intent gives the baseline its reference point. It classifies what an agent appears designed to do, who it serves, what data domain it should handle, what actions it should take, and which guardrails it declares, all from evidence captured at provisioning time. Behavior baselining checks observed activity against that reference.
Intent mismatch is a build-time posture problem: an agent's configured scope does not fit its declared purpose. Behavior drift is observed over time: the agent starts acting outside the pattern that should be normal given its intent, even if nothing about its configuration changed.
History can normalize bad design. If an agent has excessive tools or broad access from the day it was provisioned, historical behavior makes that access look ordinary rather than flagging it. Declared intent gives security teams an anchor that does not depend on the agent's own past to define what is acceptable.
Tool calls, data sources, identity mode, external destinations, action classes, audience patterns, and workflow sequence for any agent that can write, send, delete, approve, or call other agents. The strongest findings combine drift in one of these signals with meaningful blast radius, such as sensitive data or an external destination.
Some high-risk deviations warrant containment, but most should route to review first. The right response depends on data sensitivity, the privileges involved, whether the action reaches outside the organization, and whether the behavior violates the agent's own declared intent.
Feature Update
An HR agent scoped to answer benefits questions on Monday can end up pulling SSNs into a marketing chat by Friday for someone it was never intended to serve, and nothing in its permissions ever changed. The access was always there. What changed was what the agent decided to do with it. A prompt injection, poisoned context, a memory update, or an unexpected tool response can push it into work that no longer matches its original intent. Agent Behavior Baselining is built to catch that.
Today it gets easier to see: drift against intent now renders in the Agent Detail pane, so a security team can trace how an agent's actual behavior tracks its declared purpose over time, not just read a finding after the fact.
A financier isn't a developer, neither is a marketing ops leader, but both are still creating agents that often end up overprivileged. The underlying problem is not that agents get reconfigured carelessly but rather that agents drift into risky work without any configuration changes at all. The identity, the permissions, and the tool list all look exactly the same as they did yesterday. What changed is the action the agent actually took.
That is a hard problem for approaches built purely from historical activity. Watching an agent's behavior over time and flagging deviation from its own history is a reasonable starting point, and it is the model most of the market has converged on. It has a structural weakness: if an agent was provisioned with excessive tools or broad access from the start, historical behavior teaches the monitoring system that the excess is normal. The baseline calibrates to the risk instead of catching it. A statistical baseline also has no independent way to judge whether a given action belongs to the agent in the first place. An incident response agent accessing a database, restarting a service, and opening a ticket is unremarkable. A public support bot doing the same thing deserves immediate review. The action alone does not carry that distinction.
That distinction comes from declared intent. Agent Intent classification separates an agent's posture into distinct dimensions: who it is meant to serve, what topic or data domain it should handle, what action classes it should take, what goal it is pursuing, and which guardrails it declares, all inferred from evidence captured at provisioning time rather than learned from watching the agent run. Agent Behavior Baselining extends that classification forward into observed patterns: tool use, data access, identity mode, workflow sequence, destinations, audience, volume, and timing.
Agents are also supposed to adapt, so alerting on every new path drowns the signal that matters. A finance agent calling a planning spreadsheet more often near month-end is not a finding. A read-only HR policy agent picking up a tool that can send external email is. The stronger signal combines drift with blast radius, the pattern behind what's sometimes called the lethal trifecta of sensitive data, untrusted input, and external reach. The risk shows up in the chain: the action, the data involved, the identity it ran under, the destination, and the agent's declared purpose no longer line up.
When a finding surfaces, the review stays grounded in four questions: what changed, which intent dimension it touches (audience, topic, action, goal, or guardrail), what the agent could reach or change as a result, and whether the behavior still matches the agent's declared purpose.
Agent Behavior Baselining has been running in the Opsin platform, comparing observed agent behavior against declared intent and surfacing findings when the two diverge. What's new is how that comparison shows up for the security team reviewing it.
The Agent Detail pane now shows drift as a direct comparison against declared intent, not a standalone text alert. Each agent's Agent Intent block states its declared purpose and explicitly out-of-scope activity, alongside the sensitive data types and knowledge sources it touches. Below that, Typical Initiators, Typical Topics, and Typical Actions show the intent-aligned baseline side by side with an anomalies column, so a reviewer sees the normal pattern (e.g. HR and Finance users, contract and compliance topics) directly next to what broke from it (a guest or marketing user initiating the agent, a query into executive salary negotiation details). Each anomaly is tied back to the specific intent dimension it violates, so a CISO scanning the pane can tell at a glance which agents drifted, where, and why it matters.
This does not change how the baseline is built. It changes how quickly a reviewer can answer the question the baseline was built to ask: does this agent still behave like the agent it was declared to be?
This feature update extends the same declared-intent anchor already live in the Agent Detail pane, and Opsin is continuing to expand the underlying classification of tools, MCP servers, and data connections each agent can reach.
To learn more about Opsin’s Behavior Baselining, contact your Opsin Customer Success Manager.
