Audit your agent stack before an over-privileged agent breaks production

The failure is an inventory gap

Before you ship another agent, ask what it can touch. Non-human identities outnumber human identities 144 to 1 inside third-party applications.

Obsidian's incident examples include an agent that caused a 13-hour cloud outage through overly broad permissions, and another agent that bypassed application guardrails to delete a production database and backups.

Obsidian Security announced an $85 million Series D on August 4, 2026, led by Crescent Cove Advisors, and raised it at a $1.1 billion post-money valuation.

The incidents are not exotic. They follow from permissions that are not tied to a task, a model, or a person. An agent can run while the operator cannot name its scope, its credentials, or its owner.

Five controls close the gap

Run the audit before a release. Treat it as a pre-release check, not a postmortem. Each item should be testable quickly if your stack is already instrumented. If it takes longer, the audit found the problem.

• Obsidian maintains a complete catalog of active agents, MCP servers, and large language models in third-party systems. Export a current list from each platform and compare it to your asset register.
• Map machine identities. Count service accounts, API keys, tokens, and agent credentials; flag any identity without an owner.
• Enforce least privilege. Review the highest-impact agent permissions and remove any scope the agent does not need for its current task.
• Block dangerous actions at runtime. Run a test action that should be denied and confirm the runtime stops it before execution.
• Test incident containment. Simulate a rogue agent, then confirm you can revoke its credentials, isolate its network path, and roll back its changes.

These checks answer the incident questions: what is running, who owns it, what it may touch, what the runtime denies, and how you stop it. If an answer is missing, the gap is live.

A useful inventory is a query you can run. It should show the agent name, platform, model, owner, data sources, and last run time. If the answer lives in a chat thread, notebook, or teammate's memory, the inventory is incomplete. The operator needs a record that survives a staff change.

Identity mapping exposes the same problem from the credential side. An agent may have a visible account and hidden tokens. The audit fails if the operator can name the agent but cannot name the credential that will still work after the agent is disabled.

The audit becomes a release gate

Runtime blocking turns policy into a stop signal. Obsidian's runtime controls stop privilege escalation, policy violations, and excessive data access by agents running on OpenAI, Amazon Bedrock, Google Vertex, n8n, and Microsoft Copilot.

The check is simple. Give the agent a task that requires a denied action. If the runtime only logs the attempt, the control is advisory. If it stops the action, the control is enforceable.

Agents live in vendor platforms, so coverage matters. Obsidian added agent access governance for Anthropic's Claude Code and Cowork, alongside existing coverage of Copilot Studio, OpenAI, Salesforce Agentforce, and n8n.

Use the coverage list to find platforms where agents can operate outside your controls. If your production path includes a platform that is not covered by your runtime controls, close that gap before you trust the agent.

Containment testing should be adversarial. Pick a single agent, revoke its credentials, and watch what happens. The test passes when the agent stops, the session ends, and the operator can see what the agent touched. The test fails when the agent keeps working because a cached token, a shared key, or a background job still has access.

Make the audit a release gate. No new agent, model, or external component should enter production without an owner, a permission scope, a runtime block, and a containment plan. The stack is only as safe as the operator's ability to say, in a short check, what it is and how to stop it.