AI security tools, sorted by what they can prevent
AI security tooling splits into detection that reduces how often something goes wrong and enforcement that limits what a failure costs. What each layer covers, and which risks only the second one reaches.
The problem
What this is actually about
The tooling in this market divides more cleanly than the marketing does. Guardrail models, injection classifiers and output scanners reduce how often something goes wrong at the model boundary. Posture and discovery tools tell you what exists and how it is configured. Neither is in the request path, so neither can stop a specific action.
That division matters because detection is probabilistic and an attacker only needs to succeed once. A filter that catches 99% of injection attempts still admits the hundredth, and one success is enough when the agent holds production credentials. Detection is a good basis for prioritising attention and a poor one for permitting an irreversible action.
What the platform does about it
Read from the product architecture rather than written here, so this page cannot promise something no module ships.
What is it doing right now, and should this action be allowed?
- A gateway between the agent and the tool, API or database it is calling
- A recorded decision per action, carrying agent, user, resource, context, risk, policy version and outcome
- Behavioural baselines, so a hundredfold jump in record reads reads as an anomaly rather than a busy afternoon
- Runaway protection that suspends an agent stuck in a loop before it exhausts cost or capacity
- Human approval for sensitive actions, and two-person approval for critical ones
What data may it see, combine and send outward?
- Classification from public to regulated, with PII, PHI, PCI, credentials, source code and privileged material called out
- Cross-system combination controls, because access to two datasets separately is not permission to join them
- External model controls over approved providers, permitted data classes, regions, retention and training use
- Egress protection across uploads, API calls, webhooks, prompts, exports and storage writes
Which MCP servers does it use, and what do they grant?
- A registry of MCP servers with publisher, version, hosting, tools, resources, scopes, data access and the agents using each
- An approval path from discovery through publisher verification, tool inventory, permission analysis, scan and risk score
- Per-tool risk classification, because search_files and run_shell are not the same grant
- Permission drift detection when a server quietly adds a capability it did not ship with
What exactly happened, and how far did it reach?
- A complete event trail per session: model and version, human user, tools, data, decisions, approvals, secrets and destinations
- An incident timeline to the second, including the actions policy refused
- Session replay of observable requests, tool calls, data access and results
- Blast radius across systems, records, credentials, downstream actions and affected customers
- A kill switch that revokes tokens, closes sessions, disconnects MCP and preserves evidence
What it leaves behind
The artefacts these modules produce. Evidence generated by a decision, rather than assembled for an audit afterwards.
- An allow, deny or escalate decision on every governed action
- A suspension when behaviour leaves the baseline
- A record of which data classes each agent has actually touched
- A blocked-egress event naming the data class and the destination
- An approval record per server, and the agents that depend on it
- A reauthorization demand when a server materially changes
- A defensible timeline for a security review
- Preserved evidence that survives the containment that follows it
See it working
Every claim above has somewhere on this site you can go and check it.
- Injection stopped by authority, not detection
The instruction is obeyed by the model and the action is refused anyway, because policy did not ask the model.
- Detection where detection belongs
Twelve detectors over the decision stream, used to raise an agent for review rather than to authorise one.
- What sits in the path
The enforcement point itself, specified: where it runs and what it is allowed to refuse.
Common questions
- Do we still need guardrails if actions are governed?
- Yes, and the split is clean. Guardrails reduce how often an attack reaches the point of action; enforcement limits what it costs when it does. A programme with only the second wastes effort blocking attacks that better input handling would have prevented cheaply.
- Which AI agent security risks does detection not cover?
- The ones that are properties of permissions rather than of a prediction: excessive agency, credentials outliving the purpose that justified them, delegation that widens authority, and an action in a production system that cannot be traced to an initiating principal.
- Where should the enforcement point sit?
- Close to the workload. The control plane holds inventory, policy and analytics; a gateway deployed in the customer’s own environment evaluates sensitive actions, so the decision does not depend on a round trip to somebody else’s cloud.