AI & agentic AI security architecture
You are being asked to approve AI systems faster than your control framework can assess them, and the failure modes do not look like the ones your existing standards were written for.
In most organisations the difficulty is approval rather than security. Business teams move faster than the assurance function can assess, and the existing control framework rarely describes the failure modes that apply here: prompt injection, tool misuse, data leakage through context windows, model poisoning, and agents acting autonomously with more permission than they need.
Where I usually start
Threat modelling the specific system. An internal retrieval-augmented assistant and a customer-facing agent with tool access carry different risks. Treating them the same way produces controls that are too heavy in one place and too weak in another.
Gateway before policy. An acceptable-use standard with nothing enforcing it adds exposure without reducing any. An AI gateway gives you one place to apply routing, logging, data-loss controls and model allowlisting, and gives your governance function something concrete to point at.
Agentic permissioning. Non-human identity is where most existing IAM models struggle. Agents need scoped, revocable and auditable credentials, and conditional access frameworks that treat machine identities as first class.
How this differs from an AI policy document
Plenty of firms will sell you a policy. The harder work sits underneath it: what enforces the policy, what evidence it produces, and how a reviewer decides whether a given system passes.