Most agent security programs can now answer "which agents exist and what are they connected to." Opsin’s latest feature update, Agent Defense 2.0, takes it a few steps further, answering the more critical questions: what can agents actually do with their connections and should those actions be allowed. It classifies the MCP servers and tool calls behind every agent, checks agent access against the agent's stated intent, and routes the resulting risk to the person who owns the agent.
Enterprise AI agents accumulate access quickly, especially as AI adoption across the enterprise grows. A meeting assistant gets calendar read access, then a connector added to the file share it was drafting notes from, then a credential-backed tool because someone needed it to close a workflow gap.
Each addition made sense on its own, yet none of them were reviewed against what the agent was originally intended for. Multiply that across a few hundred agents connected through MCP servers and tool calls, and most security teams lose the ability to say with confidence what any given agent can actually reach.
Static permission reviews don’t solve this growing problem. They confirm that access was granted, not whether it should have been. Runtime behavior baselines have the opposite effect: if an agent was overprivileged from day one, its early activity becomes the baseline, and a bad configuration quietly looks normal. Generic anomaly detection sits on top of both and still cannot tell a reviewer whether a specific tool call, talking to a specific MCP server, on a specific piece of sensitive data, was ever something the agent was meant to do.
Opsin approached this by treating the agent's connections as classified security objects, not as a flat inventory line. Every MCP server and tool call an agent can invoke gets evaluated for what it can process, where it can reach, and what it can change. That classification is then checked against agent intent, the declared purpose an agent was provisioned with, rather than against whatever the agent happened to do first. The result is a posture question a reviewer can actually answer: does this agent's access match what it was built to do, and if not, where is the gap.
Inside Agent Defense 2.0, every agent now has a data connections view that lists the MCP servers and tool calls it can invoke, each tagged by data sensitivity, external reach, and whether it can ingest untrusted input. This replaces a flat list of integrations with a classified map of where an agent's access actually leads.
Agent Defense 2.0 lines that map up against agent intent. For this release, intent is scoped to the actions an agent is expected to be able to take, since that facet ties most directly to concrete security risk. Where a connection falls outside the agent's expected actions, or where it combines with other risky connections on the same agent, Opsin surfaces a posture issue rather than leaving it buried in a permissions list.
The findings that matter most are combinations, not single facts. An agent that can process untrusted input, hold sensitive data access, and send information externally is a materially different risk than an agent with any one of those properties alone. Agent Defense 2.0 is built to surface that convergence directly, so a reviewer sees the combination, not three unrelated line items they have to connect themselves.
Each issue is tied to the agent's owner, so remediation has a person attached to it from the start. The workflow gives that owner a specific recommended action, such as narrowing the agent's scope, restricting a tool call, or changing how a connection authenticates, instead of a generic instruction to "review access."
Agent Defense 2.0 extends the intent-based approach Opsin introduced with Agent Intent and Agent Behavior Baselining down into the specific connections an agent can use. Additional intent facets and posture issue types are on the roadmap as this rolls out further.
Agent Defense 2.0 is an Opsin capability that classifies the MCP servers and tool calls behind every AI agent and evaluates whether that access matches the agent's intended purpose, so security teams can see what an agent can reach and act on gaps.
Each MCP server and tool call is evaluated for the sensitivity of the data it can access, whether it can reach outside the trusted environment, and whether it can process untrusted input, rather than being treated as a single undifferentiated integration.
Agent intent is the declared purpose an agent was provisioned with. Agent Defense 2.0 checks an agent's actual connections against the actions it was expected to be able to take, rather than relying on observed runtime activity as the baseline.
A single permission rarely tells the full story. Risk rises when sensitive data access, untrusted input, and external reach converge in the same agent, so Agent Defense 2.0 is built to surface that convergence as a single finding.
Findings are tied to the agent's owner and paired with a specific recommended action, such as narrowing scope or restricting a tool call, so the person responsible for the agent has a clear next step.
Most agent security programs can now answer "which agents exist and what are they connected to." Opsin’s latest feature update, Agent Defense 2.0, takes it a few steps further, answering the more critical questions: what can agents actually do with their connections and should those actions be allowed. It classifies the MCP servers and tool calls behind every agent, checks agent access against the agent's stated intent, and routes the resulting risk to the person who owns the agent.
Enterprise AI agents accumulate access quickly, especially as AI adoption across the enterprise grows. A meeting assistant gets calendar read access, then a connector added to the file share it was drafting notes from, then a credential-backed tool because someone needed it to close a workflow gap.
Each addition made sense on its own, yet none of them were reviewed against what the agent was originally intended for. Multiply that across a few hundred agents connected through MCP servers and tool calls, and most security teams lose the ability to say with confidence what any given agent can actually reach.
Static permission reviews don’t solve this growing problem. They confirm that access was granted, not whether it should have been. Runtime behavior baselines have the opposite effect: if an agent was overprivileged from day one, its early activity becomes the baseline, and a bad configuration quietly looks normal. Generic anomaly detection sits on top of both and still cannot tell a reviewer whether a specific tool call, talking to a specific MCP server, on a specific piece of sensitive data, was ever something the agent was meant to do.
Opsin approached this by treating the agent's connections as classified security objects, not as a flat inventory line. Every MCP server and tool call an agent can invoke gets evaluated for what it can process, where it can reach, and what it can change. That classification is then checked against agent intent, the declared purpose an agent was provisioned with, rather than against whatever the agent happened to do first. The result is a posture question a reviewer can actually answer: does this agent's access match what it was built to do, and if not, where is the gap.
Inside Agent Defense 2.0, every agent now has a data connections view that lists the MCP servers and tool calls it can invoke, each tagged by data sensitivity, external reach, and whether it can ingest untrusted input. This replaces a flat list of integrations with a classified map of where an agent's access actually leads.
Agent Defense 2.0 lines that map up against agent intent. For this release, intent is scoped to the actions an agent is expected to be able to take, since that facet ties most directly to concrete security risk. Where a connection falls outside the agent's expected actions, or where it combines with other risky connections on the same agent, Opsin surfaces a posture issue rather than leaving it buried in a permissions list.
The findings that matter most are combinations, not single facts. An agent that can process untrusted input, hold sensitive data access, and send information externally is a materially different risk than an agent with any one of those properties alone. Agent Defense 2.0 is built to surface that convergence directly, so a reviewer sees the combination, not three unrelated line items they have to connect themselves.
Each issue is tied to the agent's owner, so remediation has a person attached to it from the start. The workflow gives that owner a specific recommended action, such as narrowing the agent's scope, restricting a tool call, or changing how a connection authenticates, instead of a generic instruction to "review access."
Agent Defense 2.0 extends the intent-based approach Opsin introduced with Agent Intent and Agent Behavior Baselining down into the specific connections an agent can use. Additional intent facets and posture issue types are on the roadmap as this rolls out further.
