The 8th Domain: AI Security's Missing Control Category

Walk into any enterprise security review for an AI project in 2026 and you will see the same checklist. OWASP Top 10 for LLM Applications. NIST AI Risk Management Framework. EU AI Act Article 15. MITRE ATLAS. The company’s own model card requirements. The reviewer ticks through data privacy, model provenance, prompt hardening, output filtering, identity management, audit logging, supply chain risk. Seven domains. All documented. All reviewable.

Then the agent ships. It runs as a service identity with OAuth grants to read and write on the CRM, query the analytics warehouse, send messages on behalf of users in Slack, file tickets in Jira, refund payments in Stripe. The reviewer signed off because every domain on the checklist was addressed. None of them was the right question.

The right question is: when this agent decides to take an action at runtime, who authorized that specific action?

That question belongs to a security domain that does not exist yet in most enterprise frameworks. Call it the eighth domain: Agent Runtime Authorization.

The seven domains everyone talks about

The current consensus 7-domain framework for AI security, as it appears across OWASP, NIST, the EU AI Act, and most enterprise AI risk programmes, looks roughly like this:

1. Data privacy and lineage, what training data, what runtime data, what retention.
2. Model integrity, provenance, tamper detection, fine-tuning controls.
3. Input security, prompt hardening, jailbreak resistance, injection detection at the prompt layer.
4. Output safety, toxicity, hallucination, PII leakage in responses.
5. Identity and access, human authentication, authorization to use the AI system.
6. Audit and compliance, who used what, when, regulatory evidence.
7. Supply chain, third-party models, libraries, vector stores, API providers.

Every one of these has frameworks, tooling, vendor categories, and SOC playbooks. Together they cover most of what a generative AI deployment needs to be safe.

What they do not cover is the moment an autonomous agent decides to call a tool.

What the eighth domain actually controls

Agent Runtime Authorization is the control point between an AI agent and the systems it can reach. It governs what the agent is allowed to do at the moment it tries to do it. Not what the human user was allowed to do, not what the service account was provisioned with, but what this specific action by this specific agent in this specific session is authorized to perform.

OWASP’s separate Top 10 for Agentic AI Applications, published in 2025, names exactly this category of risk. AAI01 Permission Compromise. AAI02 Capability and Tool Misuse. AAI03 Memory Poisoning. AAI06 Excessive Agency. The taxonomy is well-developed. The control category to address it is not.

That control category needs five capabilities none of the other seven domains provide.

• Capability-bound execution. Each agent action runs against a capability token that defines exactly what it can do, scoped to time, resource, and operation type. Not a long-lived OAuth grant. A short-lived, narrowly-scoped capability that expires.
• Intent capture and validation. When the user asks the agent to do something, the agent’s understanding of that request is captured and bound to the resulting actions. If the agent later tries to take an action outside that intent, the action is blocked even if every other check would have allowed it.
• Per-call authorization. Every tool call passes through a policy decision point that checks the capability, the intent, and the runtime context before the call reaches the tool. Not a session-level grant that opens and stays open. A decision per call.
• Capability attenuation across delegation. When a parent agent spawns a sub-agent, the sub-agent inherits a strictly narrower capability than the parent. It can never widen. The parent remains accountable for what the sub-agent does within that narrowed scope.
• Agent-aware forensic audit. The audit record captures the agent identity, the originating intent, the capability used, the policy decisions made, and any injection vectors detected. Structured for incident response, not just compliance reporting.

These capabilities do not live in any of the seven existing domains. Identity and Access governs human authentication, not agent-runtime decisions. Audit and Compliance logs that an action happened, not why it was authorized or whether it should have been. Output Safety filters what the model says, not what the agent does.

Why now

AI agents went into enterprise production at meaningful scale in Q4 2025. As of mid-2026 most large organizations have at least a handful in pilot or limited rollout. The first wave of breach reports, agents weaponized by prompt injection to exfiltrate data, manipulate financial transactions, or compromise multi-agent supply chains, is six to twelve months out.

The regulatory clock is shorter. EU AI Act enforcement provisions for high-risk AI systems begin to bite. DORA requires demonstrable incident response capability for any AI involved in financial operations. NIS2 expands the definition of essential services in ways that pull AI-driven operational decisions into scope.

CISOs preparing for any of these have a problem. The seven-domain checklist will not satisfy a regulator asking “how do you know what your agent did at 14:23 on Tuesday and who authorized it?” The seven-domain checklist will not satisfy an incident response team trying to determine whether the customer data exfiltration was the agent following an injection or a legitimate operation.

It will not satisfy them because the answer to both questions lives in the eighth domain.

What this means for security architecture

Enterprises building or buying AI capability today should treat Agent Runtime Authorization as a first-class architectural domain. That means three things.

A control plane separate from the agent itself. Authorization decisions must be made outside the LLM, by infrastructure the agent cannot influence. A policy enforcement point inside the model’s prompt is a suggestion. A policy enforcement point on the network path the model has to traverse is a control.

A policy language that can express intent-bound, capability-scoped, time-limited authorization. RBAC and ABAC alone do not get there. The language needs primitives for capability tokens, intent assertions, delegation chains, and runtime context that traditional access policy never had to model.

Forensic outputs structured for SOC and audit, not just for the model developer. The reasoning that led to a block, the intent captured at session start, the injection vector detected mid-call, the capability that was attenuated to a sub-agent. All of it in the record, all of it queryable by an incident responder who has never read an LLM trace in their life.

Whether this gets built in-house, bought from an emerging vendor category, or assembled from open-source components is an architectural choice. Treating it as out-of-scope because it does not appear on the existing seven-domain checklist is not.

The eighth domain is the one production AI agents actually need. The frameworks will catch up. The agents are already shipping.

---

IntentGate is the gateway purpose-built for the eighth domain. Capability-bound execution, intent validation, per-call authorization, delegation attenuation, agent-aware audit. Run the demo · Read the architecture · Talk to us.