Skip to main content
When AI agents spread through a company, a security guideline is usually the first thing people ask for. But existing certifications such as SOC 2 and ISO 27001 don’t cover agent-specific risks like prompt injection, unauthorized action execution, and memory poisoning. Instead of relying on a single standard, divide the roles among several standards and layer controls to match your organization’s AI adoption level.

​
The five-layer model of standards

Start by getting stakeholders to share one premise: no single standard does everything. AI security standards don’t compete with each other. They divide into five layers, each answering a different question. Picking one standard per layer and adding more as your adoption level rises sticks better than adopting everything at once.

​
Determine your current level

Judge along two axes: autonomy, meaning how much human approval is required, and access scope, meaning whether access stops at reading or extends to writes and core systems. When in doubt, treat yourself as the higher level. Match the guideline’s scope and depth to this result. A document that concretely covers your current level plus one level ahead works better in practice than a heavyweight company-wide tome.

​
Build the three foundations

Whatever your level, produce these three artifacts first.
  1. A risk glossary : Read OWASP Top 10 for LLM and the OWASP Agentic AI Top 10 together with stakeholders and condense the shared threat vocabulary onto a single page.
  2. An AI usage policy outline : Base it on the NIST AI RMF. Japanese companies should also consult the AI Guidelines for Business, which are cross-walked to the NIST AI RMF.
  3. An agent inventory : Extend the asset management thinking of CIS Controls to AI, with a rule that any agent not in the inventory is unapproved and can be stopped immediately.
Moving to higher levels without the inventory and policy is the most common failure pattern. In a CSA survey, 82% of organizations discovered agents they didn’t know they had.

​
Decide the chapter structure

When you lay out the chapters, tie every one to a reference standard and a deliverable. This structure works as a starting point.
  1. Purpose, scope, and level definitions : Include the level table as is
  2. AI usage policy : Cover prohibited training uses, sensitive data input, and shadow AI. Indirect leakage through free-tier plans that train on usage data is the biggest risk of AI use inside an organization
  3. Agent inventory and identity management : Issue each agent its own non-human identity separate from human IDs, and enforce least privilege and short-lived credentials
  4. Data access and permission design : Build around countermeasures for the confused deputy problem and the Agents Rule of Two, which allows at most two of the following: access to sensitive data, external communication, and reading untrusted content
  5. Implementation controls : Spell out the items existing guides tend to miss: pinning tool definitions by hash to detect rug pulls, treating tool return values as untrusted to counter prompt injection, and isolating MCP servers from one another
  6. Authorization and human in the loop : Split operations into three risk tiers, with human takeover for high risk, per-action approval for medium, and session-level approval for low. Too many approval requests cause approval fatigue, so gate sensitive actions such as deletion, external sending, and data sharing with deterministic policy that sits outside the model’s judgment
  7. Logging, monitoring, and auditing : Keep encrypted logs of inputs and outputs for at least six months, tie gateway logs together with correlation IDs, and detect divergence between what was authorized and what actually happened
  8. Procurement checks for vendor agents : Require SOC 2 Type II, verification of the ISO 27001 scope, ISO/IEC 42001 certification, mapping to OWASP and ATLAS, and red teaming evidence. A product whose only claim is that it was built on responsible AI principles is a red flag
  9. Incident response : Classify AI-specific incident types and prepare the logging setup and playbooks
  10. Revision process : Include the update triggers described below

​
Layer controls level by level

Write the body as one standard and one deliverable per step. That makes clear which document to consult, what done looks like, and how far along you are. At Lv1 you protect read connections. The main steps are threat modeling with the OWASP Agentic AI Top 10 and MITRE ATLAS, input sanitization and sensitive data controls following the CIS LLM companion guide, non-human identity issuance, and audit log design. At Lv2 you govern execution. Apply the CIS agent and MCP companion guides, build an authorization matrix around the three risk tiers, roll out gradually starting with low-risk tasks while prioritizing reversibility and containment, and run red teaming based on the CSA guide. At Lv3 you answer for outcomes. Introduce quantitative evaluation, obtain or conform to ISO/IEC 42001, design trust boundaries for agent-to-agent communication, and assemble an audit package consisting of AIMS documents, model cards, runbooks, and an AI-BOM.

​
Define the revision process and update triggers

A guideline isn’t finished once written. State in the document when it gets reviewed, and run revisions as diff reports: when a spec or standard changes, write up the delta and fold it into the affected chapter along with its deliverable. Events like these serve as update triggers.
  • Fold ISO/IEC 27090 into your self-assessment when it’s officially published
  • Promote the evaluation metrics draft to a candidate standard for the evaluation layer if a standards body formally adopts it
  • Reflect NIST CAISI test suites and guidelines in procurement requirements and audit criteria once they’re published
  • Update trust boundary design as MCP and A2A security specifications are finalized
Monthly threat intelligence also feeds reviews. When a new attack technique is published, check whether the controls in the affected chapters still hold.

​
References