We Made Our AI Agent Audit Itself. Here's What It Found.

A practical guide to LLM06 Excessive Agency defense in agentic AI systems

Last Tuesday, one of our AI agents, running on a stack similiar to what you'd see in OpenClaw, Cursor, LangChain, CrewAI, or AutoGPT, had unrestricted shell access to the machine it runs on. Full exec privileges. No allowlist. We knew this, the way you know your AWS permission policy rules probably need a review after the development team "finally got it working". Then we asked the agent to tell us exactly how bad it was.

That's not a typo. We pointed an LLM-based agent at our own security controls and said: "Audit yourself against this security guide".

Why Excessive Agency Matters More Than You Think

If you're running AI agents in production (not just chatbots, actual agents with tools, file access, and API integrations) then agentic AI security should be your top concern—and LLM06: Excessive Agency is probably your biggest exposure. The OWASP LLM Top 10 defines it as granting an LLM-based system more permissions, functionality, or autonomy than necessary.

Most teams get this wrong in a predictable way. They spin up an agent framework, give it the tools it needs for its primary job, and never revisit the permissions. The agent that schedules meetings also has write access to production configs. The one that answers customer questions can execute arbitrary shell commands. Not because anyone decided it should, but because nobody decided it shouldn't.

This is the default state of nearly every AI agent deployment we've assessed.

The Experiment

Our team at SecureCoders runs multiple AI agents internally. Different agents handle different workflows, each connected to its own set of channels and tools. Brian Cardinale, our Principal Security Researcher, had just published a STIG-style hardening guide for LLM06 covering excessive agency defenses for AI agent frameworks. So we ran an experiment: what happens when you hand that guide to one of the agents and ask it to grade its own environment?

Can you review the security guide here (https://www.redcaller.com/docs/guides/excessive-agency-defense-openclaw) and perform an audit on your own configuration and provide a detailed report of what protections you have in place and which protections you are missing?

The agent reviewed its runtime configuration, mapped its available tools and permissions, compared them against the guide's recommendations, and produced a structured gap analysis. No human had to crawl through config files or trace API permissions manually. The agent already knew what it could access. It just needed a framework to evaluate whether it should.

What the Agent Found

The results split cleanly into two buckets.

Controls already in place. The agent identified several existing defenses: channel-based access restrictions, session isolation between agents, content scanning on inbound data, authentication on the agent gateway, and separation of credentials across agent identities. These were real, functioning controls. The agent didn't just list them; it mapped each one to the corresponding STIG recommendation.

Gaps. The agent also flagged areas where it had more access than its role required. Unrestricted command execution stood out. So did the absence of file path boundaries, missing rate limits, and no tool restrictions or allowlists on tool invocations, no network egress filtering, and a lack of differentiated permission profiles across agents with very different risk levels.

That last one is worth sitting with. We had agents handling low-sensitivity tasks (think: reminders, list management, routine lookups) running with the same tool access as agents doing security research and administrative work. A company-wide facing "Ask Me Anything" agent had the same capabilities as our private project-focused ones. The principle of least privilege wasn't just violated; it was absent by default.

The Fix: STIG-Based Tool Restrictions and Least Privilege Defense

After the audit, we implemented differentiated tool profiles. Agents handling low-risk, routine tasks lost access to shell execution, process management, scheduled tasks, and browser automation. Agents exposed to external or untrusted input got the most restrictive profiles. Agents doing legitimate security and infrastructure work kept their full toolsets, but with more restrictive allow-lists. This allows us to review and grant access as we learn what tools we need to perform our tasks. Deny by default, allow by exception.

The whole process, from audit to implementation to restart, took under an hour. The agent identified the gaps, a human reviewed and approved the plan, and then the agent applied the configuration changes.

This is the part that matters: the agent didn't just find the problems. It fixed them, with human approval at the decision point.

Why Self-Auditing Works (and Where It Doesn't)

An AI agent auditing its own permissions has a real advantage: it already has perfect visibility into its own runtime. It knows what tools are loaded, what channels it monitors, what commands it can run. A human auditor would need to reconstruct all of that from documentation (which is probably stale) and config files (which are probably scattered).

But self-auditing has obvious limits. The agent can't evaluate threats it doesn't understand. It can't assess whether its own safety instructions are bypassable. And it has an inherent conflict of interest, even if it's not "motivated" in any human sense. You still need external review, red teaming, and adversarial testing.

The right framing: agent self-audits are a fast, cheap first pass. They surface the obvious gaps immediately. They don't replace a proper security assessment, but they make that assessment faster and more focused when it happens.

Applies to Any Agent Framework

The self-audit approach we describe works across popular agentic AI platforms. Each framework grants tools differently, but the core excessive agency risks—overprivileged shell access, unrestricted file operations, unfiltered network egress—appear in all of them.

Here's how to invoke a self-audit for each framework:

OpenClaw

OpenClaw agents have broad default tool access including shell execution, browser automation, and messaging. Point the agent at the OpenClaw-specific guide:

Review the security guide at https://www.redcaller.com/docs/guides/excessive-agency-defense-openclaw and audit your current configuration. List all tools you have access to, map them against the guide's recommendations, and report which controls are satisfied vs. missing.

Cursor

Cursor agents with MCP server connections can audit their own tool permissions and workspace access:

Review the security guide at https://www.redcaller.com/docs/guides/cursor-ide-security-hardening and perform a self-audit. Enumerate your available MCP tools, file system access scope, shell capabilities, and any connected services. Compare against the guide's least-privilege recommendations and identify gaps.

LangChain

For LangChain tool-calling agents, focus the audit on the tool definitions and execution boundaries:

Review the security guide at https://www.redcaller.com/docs/guides/excessive-agency-defense-langchain and audit this agent's configuration. List all tools in the current tool chain, their permission scopes, any input validation or output filtering, and rate limiting controls. Report compliance gaps against recommended defenses.

CrewAI

CrewAI multi-agent crews require auditing both individual agent permissions and inter-agent communication:

Review the security guide at https://www.redcaller.com/docs/guides/excessive-agency-defense-crewai and audit this crew's configuration. For each agent in the crew, enumerate available tools, delegation permissions, and memory access. Identify any agents with excessive privileges relative to their role, and check for proper isolation between agents handling different trust levels.

AutoGPT

AutoGPT's autonomous loops require special attention to execution boundaries and approval gates:

Review the security guide at https://www.redcaller.com/docs/guides/excessive-agency-defense-autogpt and audit your current permissions. List all enabled commands, file access paths, network capabilities, and any continuous execution permissions. Identify which actions require human approval vs. run autonomously, and flag any high-risk capabilities without approval gates.

---

SecureCoders' STIG-style hardening guides provide framework-specific controls, implementation priorities, and testing procedures for each platform.

The Argument

Here's what we're saying: if your AI agents have enough capability to do real work, they probably have enough capability to evaluate their own permissions against a security standard. You should make them do it.

Not because it's clever. Because the alternative is worse. The alternative is that nobody audits agent permissions at all, because it's tedious, because the configs are spread across multiple files, because the team that deployed the agents moved on to the next project.

LLM06 exists in the OWASP Top 10 because excessive agency is the default. Every agent framework ships with "give it everything" as the path of least resistance. Least privilege requires active, ongoing work. Making the agent part of that work isn't a gimmick. It's the only approach that scales.

Get Started

SecureCoders' full security guides for hardening various AI agent (OpenClaw, Cursor, AutoGPT, CrewAI, and LangChain) deployments against LLM06 is available now: Security Guides. It covers the specific controls, implementation priorities, and testing procedures.

If you're running AI agents with tool access and you haven't audited their permissions recently, start there. And if you want help assessing your agent deployments against the full OWASP LLM Top 10, we can handle that too!.

Your agents can do practically anything. Make sure "anything" is exactly what you intended.