AI Agent Guardrails
Enforce your AI policy with runtime guardrails
Obsidian Security allows teams to deploy real-time enforcements, stopping privilege escalation, unsanctioned connections, and toxic combinations across every AI platform you run.
Obsidian Security allows teams to deploy real-time enforcements, stopping privilege escalation, unsanctioned connections, and toxic combinations across every AI platform you run.
Traditional access controls assume a known user, a known scope, and a known action. None of those assumptions hold for autonomous agents that act in seconds, span multiple platforms, and invoke MCP server tools that did not exist at when the enforcement guidance was initially created.
Enforce policy at runtime to control behavior across your agents. Evaluate every agent against OWASP-aligned risk factors in real time, and use webhooks to intercept and stop policy-violating, high-risk executions before they complete.
Enforce guardrails directly at the execution layer to stop high-risk, unapproved actions related to privilege escalation before it happens, not after the damage is done. An agent built by a Salesforce admin runs on the admin's credentials. A business analyst with no Salesforce license invokes the agent and receives CRM data the analyst has no right to access. Standard IAM never sees this happen, because the call looks like a normal API request from the admin account. Obsidian Security correlates the runner's identity with the agent's maker permissions and flags the privilege escalation in real time.
Most enterprises cannot tell you which MCP servers their agents are connected to, let alone which ones security has approved. Obsidian inventories every MCP server and manages which server your agents can access to ensure only sanctioned tools are used. Additionally, deterministic runtime block enforcement is rolling out across AI platforms over 2026, starting with Copilot.
Alert fatigue is the silent killer of agent security programs. A flat list of every theoretical risk buries the agents that actually matter. Obsidian prioritizes the riskiest agents to help focus security resources and improve your security posture.
AI agent guardrails are fixed, deterministic rules applied to dynamic agent behavior at runtime. They flag or block actions that violate policy: a lower-privileged user invoking an agent built on higher-privileged credentials, an agent reaching an unsanctioned MCP server, an orphaned agent still running on a disabled creator's tokens.
Traditional applications follow fixed control flows. A user clicks a button, an API call fires, an audit log records it. AI agents make autonomous decisions, chain tools across apps, and inherit OAuth privileges built for humans. Their action space is open-ended. A guardrail for an agent has to reason about the invoker's identity, the agent's inherited credentials, the tools it can call, and the downstream systems those tools reach. Traditional IAM was not built for any of that.
Detection flags a risk after it happens. Enforcement stops it from happening. Obsidian applies policy enforcement today: blocking unsanctioned connections at the agent layer, flagging privilege escalation, prioritizing toxic combinations for immediate review. Sub-second runtime block enforcement on agent action is rolling out across AI platforms over 2026, starting with Copilot. Talk to our team for the current enforcement coverage on the platforms you run.
The full risk registry spans Maker Mode (privilege escalation through inherited creator credentials), orphaned agents (creator account disabled but credentials still active), org-wide accessible agents paired with sensitive data, confused deputy attacks (a lower-privileged user manipulating an elevated agent), hardcoded secrets in agent configuration, unsanctioned MCP server connections, and shadow agents created without IT approval. Each factor maps to a specific platform behavior on Copilot Studio, Agentforce, n8n, Bedrock, Vertex AI, and others.
No. Obsidian's guardrails hook into AI platforms (Copilot as well as Claude, Cursor, and others in the near future) via webhooks and native APIs at the agentic layer. SaaS connectors deepen the picture for specific use cases like privilege correlation against Salesforce or Google Workspace, but you can apply guardrails to your AI agents without standing up SaaS integrations across every tool first.
Obsidian scores agents by toxic combinations: situations where multiple risk factors stack on a single agent. A shadow agent that is also org-wide accessible and connected to sensitive data is a critical-priority alert, not three medium-priority noise items. Security teams see the agents that matter first, not a flat list of every theoretical risk in the environment.
No. Obsidian operates at the platform layer through webhooks and native APIs. There is no proxy in the data path, no gateway to operate, and no agent SDK to install. Coding agents in Copilot (as well as Claude, Cursor, and others in the near future) continue to operate at full speed. Security teams gain enforcement without interfering with developer workflows.
No. Obsidian is not a gateway, proxy, or in-line filter. Gateways and firewalls require traffic redirection and create their own operational burden. Obsidian hooks directly into AI platforms where agents already live, including platform-native security webhooks (the AWS-managed MCP gateway, the Copilot security webhook) that customers often do not realize exist. Enforcement runs where the agent runs, not in a parallel data path.
