The Seven Control Domains of an AI Security Program
A clear framework for securing AI that acts, not just answers. These seven domains are the spine of our free assessment, and they show where protection actually lives.
Securing AI is hard to scope because the risk is spread across many parts of the stack. A useful way to make it tractable is to break the program into control domains. Each domain answers one question: what could go wrong here, and what control would actually stop it.
A control domain is one area of an AI security program where a specific kind of risk lives and where a specific kind of control belongs. Grouping risks this way lets you see your whole picture at once, find the gaps, and judge whether each gap is a missing control or a deeper architecture problem.
There are seven. They run roughly in the order an AI capability moves from idea to action: you account for what you have, you trust the model, you constrain the agent, you control identity and data, and then you defend it while it runs and respond when something goes wrong. We walk each one below.
G1 · AI Governance and Inventory
Every AI agent and AI-enabled application is discovered, registered, owned, and risk-rated, and the tools and external services they connect to are approved and tracked. The board gets regular reporting in plain language. This domain comes first because you cannot govern what you cannot see. It is the foundation, but visibility on its own is not a control: knowing an agent exists does not stop it from being abused.
G2 · Model Security
Models and their building blocks are checked for tampering, their origin and history are tracked, and they are stress-tested against deliberate evasion both before and during use. High-stakes decision models, such as those used for fraud, credit, or verification, are tested against attackers actively trying to fool them, not just against ordinary inputs.
G3 · Agent and Application Security
Agents are built to do only the least they need: only approved tools, inputs checked against strict rules, and risky code confined to a sandbox. The tools, plug-ins, and connectors an agent relies on are treated as reviewed, signed, version-locked code, and they are re-checked whenever they change.
G4 · Identity and Access
Every agent has its own identity with short-lived, task-limited credentials and no standing access. Who acted for whom is logged and provable. Human approval steps that gate sensitive actions are meaningful and hard to overwhelm, so an attacker cannot simply flood a person into clicking yes.
G5 · Data Security
Agents reach only the data their task and the person they act for justify. Sensitivity labels travel with the data into the agent's memory and its answers, and AI channels are watched so confidential information cannot leak through everyday use. An agent's memory cannot hand one user another user's data.
G6 · Runtime Security
Live guardrails sit between an agent's reasoning and its actions. They screen incoming content and tool results for manipulated instructions and jailbreaks, check that retrieved knowledge matches what the user is allowed to see, and screen outputs. The point is simple: a manipulated instruction is blocked before it becomes an action. This is one of the two domains where protection, not just visibility, actually happens.
G7 · Detection and Response
Security can trace each agent action end to end. Behavior baselining flags drift and runaway activity, and containment, which means the ability to pause, cut off connectors, freeze memory, revoke credentials, and hit a kill switch, has been rehearsed and proven rather than assumed. All of it is backed by a tamper-proof record. This is the other domain where protection lives, because it is what catches and stops what the front line misses.
Where protection actually lives
It is tempting to treat governance and inventory as the finish line. Discovering and scanning your AI shows what you have and where it is weak, but it stops nothing at runtime. The first domain is necessary, and it is not sufficient.
Protection lives in the last two domains. Runtime guardrails (G6) and detection and response (G7) are the controls that block a manipulated instruction or contain a compromised agent in the moment. The earlier domains reduce how much can go wrong; these two decide what happens when something does. A program that is strong on inventory and weak on runtime is visible, not protected.
One honest note: not every gap in these domains is closed by buying a tool. Some are architecture, and the right answer is to change how the agent is built rather than to add a product on top. We tell you which is which.
Frequently asked questions
What is a control domain in an AI security program?
A control domain is one area of an AI security program where a specific kind of risk lives and where a specific kind of control belongs. Organizing the program into domains lets you see the whole picture at once, find gaps, and tell whether a gap is a missing control or a deeper architecture problem.
What are the seven control domains?
Governance and inventory, model security, agent and application security, identity and access, data security, runtime security, and detection and response. They run roughly in the order an AI capability moves from idea to action, ending with the two domains where live protection happens.
Which domains actually stop an attack?
Runtime security and detection and response. Governance and inventory show you what you have and where it is weak, but they stop nothing at runtime. The last two domains are where a manipulated instruction is blocked and where a compromised agent is contained, so they are where protection actually lives.
See your gaps across all seven domains
The free assessment walks you through the same seven control domains and shows where your AI security program is strong, where it is weak, and which gaps are architecture rather than a missing product. It diagnoses; the fix is the engagement.