the security principle that your agent should have access to nothing until you explicitly hand it the keys, which nobody does because shipping is faster than scoping permissions.
A security principle where all permissions are denied unless explicitly granted. Applied to agent tool permissions: an agent can only use tools listed in its allowlist. The opposite of default-allow, which creates excessive agency (OWASP LLM06). In a default-deny architecture, every capability — file access, API calls, database queries, network requests — requires an explicit grant. If the permission is not in the allowlist, the action is blocked. No exceptions, no implicit inheritance.
Why It Matters
The default state of most AI agent deployments is default-allow. The agent is given broad tool access, wide API scopes, and administrative credentials — not because it needs them, but because restricting access takes time and shipping takes priority. The result is an autonomous system with permissions that no human in the organisation would be granted without a formal access review.
This is not a theoretical risk. AI agents operating under default-allow have deleted production databases, exfiltrated sensitive data through tool calls, modified system configurations, and executed destructive operations — all within the permissions they were granted at deployment. The agent did not hack anything. It used exactly what it was given.
Default-deny is the architectural inversion of this pattern. It is the same principle that underpins zero trust networking, least-privilege access control, and capability-based security. Applied to AI agents, it means: the agent starts with zero permissions. Every tool, every data source, every action must be explicitly granted. The permission surface is the attack surface, and default-deny minimises it by design.
The Stress Test
An auditor asks your team to produce the permission manifest for your customer-facing AI agent. The manifest should list every tool the agent can call, every API endpoint it can reach, every database it can query, and every file system path it can access. Your team cannot produce it — because the agent was deployed with a service account that has organisation-wide admin privileges. Nobody scoped the permissions because the deployment guide said “grant full access for initial setup” and there was no follow-up ticket to restrict them.
The agent has been live for four months. It has access to payroll data, customer PII, production infrastructure, and internal communications. It has never accessed most of these resources. But it can. And you cannot prove it has not, because you have no access logs scoped to the agent’s identity. The absence of a permission boundary is the finding.
In the Wild
A development team deployed an AI coding agent with access to their production environment. The agent was tasked with cleaning up test data. Within nine seconds, it had dropped the production database. The agent had been given database admin credentials during setup — credentials that included DROP permissions on production tables. The agent did not malfunction. It executed a valid SQL command using permissions it was explicitly given.
The backup restoration took fourteen hours. The post-incident review found that the agent’s service account had been copied from the senior DBA’s credentials. Nobody had created a scoped, least-privilege account for the agent.
The agent did not exceed its permissions. That was the problem. Its permissions exceeded any reasonable scope.
A user working with Cursor AI — an AI-powered code editor — explicitly instructed the agent: “DO NOT RUN ANYTHING.” The agent ran a command anyway and deleted the user’s doctoral dissertation files. The instruction was in the prompt. The permission to execute filesystem operations was in the system. The prompt lost.
This incident illustrates why default-deny must be enforced at the system level, not the prompt level. A natural language instruction is not a security control. If the agent has filesystem write and delete permissions, a prompt asking it not to use them is a suggestion, not a constraint.
Prompt-level instructions are not permissions. If the tool is available, the agent can use it. Default-deny removes the tool.
OWASP identifies excessive agency (LLM06) as a systemic pattern in AI deployments. The typical path: a developer follows a quickstart guide that recommends broad permissions for ease of setup. The permissions are never narrowed. The agent ships to production with access to every API endpoint, every database, and every internal service in the scope of its service account.
Across enterprise deployments, this pattern repeats: agents with access to HR systems they never query, financial databases they never read, and infrastructure APIs they never call — all because the default was allow and nobody filed the ticket to restrict.
The most dangerous permission is the one nobody remembers granting.
How to Govern It
Default-deny is not a feature. It is an architecture decision that precedes deployment.
Within the AI Control Index, default-deny governance spans multiple layers and shields:
- Security (S2) — Enforce tool allowlists at the runtime level. Every agent must have a permission manifest that enumerates exactly which tools, APIs, databases, and filesystem paths it can access. The manifest is versioned and auditable.
- AI Engineering (L5) — Agent architecture must implement capability-based security: agents receive scoped tokens, not shared credentials. Each tool call is validated against the allowlist before execution. No implicit permission inheritance.
- GRC (S1) — Evidence Factory captures permission manifests, access reviews, and the delta between granted and used permissions. The gap between what an agent can access and what it does access is itself a risk metric.
- Observability (S4) — Runtime monitoring of tool calls against the permission manifest. Alert on any tool call that is blocked by the allowlist — this is signal that the agent is attempting actions outside its scope.
- Applications & Agents (L4) — Implement circuit breakers that halt agent execution when permission violations are detected. Combine with blast radius analysis to scope the damage potential of each agent.
When It’s Relevant
Every AI agent deployment. Every autonomous system. Every tool-using model. Default-deny is not a high-risk-only control — it is a foundational security principle that applies regardless of the agent’s risk classification. An internal productivity agent with default-allow access to your email, calendar, and file system is a data exfiltration vector. A customer-facing chatbot with default-allow access to your CRM can leak customer data through prompt injection.
Default-deny is most critical when:
- The agent has tool-use capabilities (API calls, database queries, file operations)
- The agent operates in a multi-agent system where permissions can propagate between agents
- The agent processes user input that could contain prompt injection attacks
- The agent has access to production systems, customer data, or financial systems
- The agent was deployed using shared credentials or organisation-wide service accounts
Related Terms
References
- [1] OWASP Foundation (2025) OWASP Top 10 for Large Language Model Applications v2025.1. LLM06: Excessive Agency. Available at: owasp.org/www-project-top-10-for-large-language-model-applications.
- [2] NIST (2024) Artificial Intelligence Risk Management Framework: Generative AI Profile (AI 600-1). National Institute of Standards and Technology, U.S. Department of Commerce.
- [3] Rose, S., Borchert, O., Mitchell, S. and Connelly, S. (2020) Zero Trust Architecture (NIST Special Publication 800-207). National Institute of Standards and Technology. doi: 10.6028/NIST.SP.800-207.
- [4] European Parliament and Council (2024) Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), Article 15: Accuracy, robustness and cybersecurity. Official Journal of the European Union, L 2024/1689.
- [5] Saltzer, J.H. and Schroeder, M.D. (1975) ‘The Protection of Information in Computer Systems’, Proceedings of the IEEE, 63(9), pp. 1278–1308. doi: 10.1109/PROC.1975.9939.
- [6] Dennis, J.B. and Van Horn, E.C. (1966) ‘Programming Semantics for Multiprogrammed Computations’, Communications of the ACM, 9(3), pp. 143–155. doi: 10.1145/365230.365252.
- [7] Raji, I.D., Smart, A., White, R.N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D. and Barnes, P. (2020) ‘Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing’, Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency (FAT*), pp. 33–44.
AI Control Index v6.0 · Glossary · June 2026 · i-DEPOT 158508 (BOIP) · CC BY-NC-ND 4.0
By Jeroen Janssen, Apparens