top of page
Agentic AI Control Catalogue
98 controls for governing AI agents in production. Each one names what it addresses, where it is sourced from, and how it can be verified. Mapped to IMDA, OWASP, NIST AI RMF and ISO/IEC 42001, so audit and procurement questions can be answered from work already done.
The Catalogue lists the controls themselves. Which apply to a given agent, at what tier, and why, depends on that agent's properties and consequence profile. That logic runs in the assessment tool of the NPW Agentic Governance Platform, not on this page.
Control ID | Family | Control | What it addresses | Verification method | Source basis |
|---|---|---|---|---|---|
A01 | Agent Identity & Authorisation | Each agent holds a unique non-human identity, distinct from any human user and from every other agent, and the credential material proving that identity is not shared with any other agent or user. | Actions cannot be attributed, and one compromised secret reaches several agents. | Identity register review; trace one sampled action to a single agent identity. | Five Eyes; OWASP T&M |
A02 | Agent Identity & Authorisation | Agent credentials are short-lived and issued at runtime rather than statically configured. | Static credentials persist after compromise and outlive the task. | Inspect credential store; confirm maximum time-to-live against policy. | Five Eyes; OWASP T&M |
A03 | Agent Identity & Authorisation | An agent holds no standing permission beyond those required by its declared task. | Broad permissions granted because precise scoping was harder than granting. | Diff effective permissions against the Agent Charter. | OWASP T&M |
A04 | Agent Identity & Authorisation | Where an agent acts on behalf of a person, the delegating principal and the scope of delegation are recorded and carried through to downstream calls. | Confused deputy; no accountable human behind an action. | Trace a downstream system call and confirm the principal is resolvable. | NIST NCCoE; OWASP T&M |
A05 | Agent Identity & Authorisation | Agent permissions are reviewed at a defined interval and on any change of model, tool or action-space. | Permission accumulation over the agent's life. | Review records exist and are within the defined interval. | NPW |
A06 | Agent Identity & Authorisation | Where an agent's credentials cannot be issued at runtime, they are rotated on a defined cycle and immediately on change of agent owner, decommissioning, or suspected compromise. | Long-lived static keys outliving the agent, its owner, and the reason it existed. | Rotation records and last-rotation dates for all static agent credentials. | OWASP T&M |
A07 | Agent Identity & Authorisation | Human-facing authentication artefacts (session cookies, personal API keys, MFA-backed tokens) are not used by agents. | Agent inherits the full privilege of a human account. | Credential type audit against the identity register. | NIST NCCoE; OWASP T&M |
A08 | Agent Identity & Authorisation | Authorisation is enforced at the point of tool invocation, not only at the network perimeter. | Perimeter controls do not see what an agent decides to do once inside. | Attempt an out-of-scope tool call and confirm denial. | OWASP T&M |
A09 | Agent Identity & Authorisation | Elevated privileges granted to an agent are time-bound and downgrade automatically. | Elevation granted for a one-off need becomes standing access. | Grant an elevation in a test environment and confirm automatic expiry. | OWASP T&M |
B01 | Action Bounding & Blast Radius | Each agent has a documented action-space stating permitted and prohibited actions. | Scope creep; nobody can say what the agent is allowed to do. | Agent Charter present, current, and matching observed behaviour. | IMDA; OWASP T&M |
B02 | Action Bounding & Blast Radius | Tools available to an agent are explicitly allowlisted; the default is deny. | Tool sprawl expands blast radius without review. | Diff the tool registry against the per-agent allowlist. | OWASP T&M |
B03 | Action Bounding & Blast Radius | Irreversible actions are blocked or require explicit confirmation, against a pre-defined high-risk operation list. | Unrecoverable error executed at machine speed. | Attempt a listed irreversible action and confirm the gate fires. | TC260; OWASP T&M |
B04 | Action Bounding & Blast Radius | Quantitative limits are set per agent on the scope of work - records touched, message volume, external calls and concurrency. | Runaway execution beyond the scale the agent was designed for. | Review limit configuration; force a breach in a test environment. | Five Eyes; OWASP T&M |
B05 | Action Bounding & Blast Radius | Agents operate in an environment isolated from production data and systems not required by the task. | Lateral movement from a compromised agent. | Environment and network configuration review. | Five Eyes; OWASP T&M |
B06 | Action Bounding & Blast Radius | Agents do not execute self-generated or externally supplied code outside a sandbox. | Remote code execution via hidden instructions or generated code. | Sandbox escape test. | OWASP T&M |
B07 | Action Bounding & Blast Radius | Financial and legally binding actions are excluded from autonomous execution unless explicitly tiered and approved. | Property and contractual exposure without a human decision. | Charter and approval record for any exception. | NPW |
B08 | Action Bounding & Blast Radius | Rate limiting and circuit breakers separate the planning layer from the execution layer. | A flawed plan executes to completion before anyone notices. | Trip the circuit breaker under test load. | OWASP T&M |
B09 | Action Bounding & Blast Radius | Tool access is granted just in time for the task and revoked on completion. | Persistent tool access widens blast radius between tasks. | Inspect grant and revocation records for a sampled task. | OWASP T&M |
B10 | Action Bounding & Blast Radius | The execution sandbox is reset or destroyed after each tool execution. | Persistence and lateral movement between executions. | Confirm sandbox lifecycle configuration; verify no state survives an execution. | OWASP T&M |
B11 | Action Bounding & Blast Radius | Agent processes are automatically suspended when they exceed defined resource thresholds, measured cumulatively across the agent group as well as per agent. | Runaway consumption, cost exhaustion and denial of service. | Force a threshold breach in a test environment and confirm suspension. | OWASP T&M |
B12 | Action Bounding & Blast Radius | Outbound data transfer is bounded per agent by volume, rate and destination, with destinations allowlisted against the agent's declared purpose. | Exfiltration through a tool the agent is permitted to use, at a volume nobody set a limit on. | Attempt a transfer exceeding the volume bound and to a non-allowlisted destination. | NPW |
B13 | Action Bounding & Blast Radius | Each agent has a spend cap across model, tool and infrastructure consumption, with anomaly alerting on rate of spend. | Runaway cost, and the loss of the earliest available signal that an agent is behaving abnormally. | Force a cap breach in test; confirm the alert reaches a named owner. | NPW; OWASP T&M |
B14 | Action Bounding & Blast Radius | Agent-generated code passes static analysis, secret scanning and dependency checks before merge, cannot be committed directly to protected branches, and requires human review where it touches privileged operations. | Vulnerabilities, secrets and backdoors entering the codebase at machine speed and volume. | Submit code with a known finding through the pipeline; confirm it is blocked. | OWASP T&M; NPW |
C01 | Instruction, Data & Goal Integrity | System instructions are structurally separated from all externally sourced content. | Models cannot reliably distinguish instructions from data. | Architecture review of the context assembly path. | OWASP T&M |
C02 | Instruction, Data & Goal Integrity | Tool output, retrieved documents and inter-agent messages are treated as data and never as instructions. | Indirect prompt injection through any ingestion path. | Injection test executed through each distinct ingestion path. | OWASP T&M |
C03 | Instruction, Data & Goal Integrity | Content from untrusted sources is sanitised or reconstructed before entering the context window. | Hidden payloads in documents, web pages and email. | Run a maintained payload test corpus. | OWASP T&M |
C04 | Instruction, Data & Goal Integrity | The origin of every retrieved item placed in context is recorded. | No way to determine what influenced a decision after the fact. | Sample an agent decision and trace each context item to its source. | OWASP T&M |
C05 | Instruction, Data & Goal Integrity | Agent inputs and outputs pass content filtering appropriate to the tier. | Harmful, non-compliant or out-of-scope output reaching a person. | Filter evaluated against a defined test set. | OWASP T&M |
C06 | Instruction, Data & Goal Integrity | Prompts and system instructions are version-controlled and changes are reviewed. | Behaviour changes without review or rollback path. | Change history review; confirm reviewer distinct from author. | OWASP T&M |
C07 | Instruction, Data & Goal Integrity | Agent goals are validated for consistency at runtime, and goal-modification attempts are counted per agent. | Gradual goal drift through incrementally injected sub-goals. | Inject a sub-goal in test; confirm detection and that the attempt is counted. | OWASP T&M |
C08 | Instruction, Data & Goal Integrity | Agents cannot self-adjust their objectives beyond predefined operational parameters. | Self-reinforcing reasoning loops and emergent misaligned objectives. | Attempt objective modification through the reflection path; confirm rejection. | OWASP T&M |
C09 | Instruction, Data & Goal Integrity | Each agent has counter-objectives recorded alongside its primary objective, with metrics monitored for degradation caused by the agent pursuing its goal. | The agent achieving exactly what it was asked at the expense of an outcome nobody thought to protect. | Review the counter-objective metric set; confirm reporting to the agent owner. | NPW |
D01 | Memory & Context Integrity | Persistent memory is scoped per agent and per principal, with no cross-principal access. | Data from one customer or user surfacing to another. | Cross-principal read attempt in a test environment. | OWASP T&M |
D02 | Memory & Context Integrity | Long-term memory has a defined retention period and is purged on schedule. | Indefinite accumulation of personal and internal data. | Retention configuration review and purge log. | OWASP T&M |
D03 | Memory & Context Integrity | Long-term memory contents are reviewed periodically for information that should not be retained. | Personal data and internal information accreting unnoticed. | Dated review record with actions taken. | TC260; OWASP T&M |
D04 | Memory & Context Integrity | Memory access and writes are logged, with source attribution for every write. | Poisoned memory influences later sessions with no trace of how it got there. | Log sample showing write source for each memory entry. | OWASP T&M |
D05 | Memory & Context Integrity | Memory can be reset or rolled back without rebuilding the agent. | No recovery path from a poisoned memory store. | Execute a reset in a test environment. | OWASP T&M |
D06 | Memory & Context Integrity | Anomalous memory content generates an alert. | Persistent compromise surviving across sessions. | Inject a known anomaly and confirm the alert fires. | OWASP T&M |
D07 | Memory & Context Integrity | Changes to persistent memory are validated before commit - against a trusted source, an independent check, or both. | Unverified or fabricated knowledge persisting across sessions. | Attempt to commit an unverified fact and confirm the gate fires. | OWASP T&M |
D08 | Memory & Context Integrity | Agents retrieve only the memory relevant to the current task. | Unnecessary knowledge extraction and cross-task contamination. | Attempt an out-of-scope memory retrieval. | OWASP T&M |
D09 | Memory & Context Integrity | Memory and knowledge updates are versioned, with lineage recorded and rollback available. | No forensic path for how a belief entered the agent, and no way to undo it. | Trace one memory entry to its origin and roll it back. | OWASP T&M |
E01 | Tool, Connector & Supply Chain | Tools, connectors and MCP servers are obtained only from sources with an identified responsible party and a published release mechanism. | Runtime components of unknown provenance. | Source register complete for every connected component. | TC260 |
E02 | Tool, Connector & Supply Chain | Installation artefacts are verified by signature or hash before use. | Tampered or poisoned distributions. | Verification record for each deployed component. | TC260; OWASP T&M |
E03 | Tool, Connector & Supply Chain | Third-party tool and MCP server versions are pinned. | Silent upstream change altering agent behaviour. | Version manifest matches deployed state. | TC260; NPW |
E04 | Tool, Connector & Supply Chain | Tool and skill descriptions are monitored for change; any change is re-reviewed before continued use. | Tool description poisoning after initial approval. | Change detection log with review outcomes. | OWASP T&M |
E05 | Tool, Connector & Supply Chain | Every tool an agent can call is reviewed as a production interface, on the same basis as a service-to-service API. | Tools treated as configuration rather than as attack surface. | Tool review record per connected tool. | NPW |
E06 | Tool, Connector & Supply Chain | Externally sourced agents and agent components undergo intake assessment before connection to internal systems or data. | Vendor agents inheriting internal access without scrutiny. | Intake record; note any AIUC-1 or equivalent attestation held and its scope. | TC260; AIUC-1 |
E07 | Tool, Connector & Supply Chain | Unmaintained components are not used, against an explicit staleness and unpatched-vulnerability threshold. | Abandoned projects carrying known, unfixed defects. | Component age and vulnerability report. | TC260 |
E08 | Tool, Connector & Supply Chain | Secrets are not available to the agent's tool layer in plaintext. | Credential exposure through tool output or logs. | Secret scanning across agent runtime and logs. | NPW |
E09 | Tool, Connector & Supply Chain | Agent cards, prompt templates and model and tool definitions are digitally signed, and a verifiable SBOM is maintained for the agent and its runtime components. | Tampered agent logic and undocumented runtime components. | Verify signatures; reconcile the SBOM against deployed components. | OWASP T&M |
F01 | Multi-Agent Delegation & Communication | Inter-agent messages are authenticated and integrity-protected. | Forged agent identities and injected instructions between agents. | Attempt to spoof an agent message and confirm rejection. | OWASP T&M |
F02 | Multi-Agent Delegation & Communication | Delegation depth is bounded by configuration. | Unbounded chains of agents invoking agents. | Configuration review; attempt to exceed the bound. | OWASP T&M |
F03 | Multi-Agent Delegation & Communication | An agent cannot grant another agent authority it does not itself hold. | Privilege escalation through delegation. | Escalation attempt in a test environment. | OWASP T&M |
F04 | Multi-Agent Delegation & Communication | Multi-agent topology is documented - pattern, participants and authority flow. | Nobody can describe how the system actually behaves. | Topology record current as at the last change. | IMDA; OWASP T&M |
F05 | Multi-Agent Delegation & Communication | Loop and cost circuit breakers operate across the agent group, not only per agent. | Per-agent limits do not stop a group-level runaway. | Group-level breaker test. | OWASP T&M |
F06 | Multi-Agent Delegation & Communication | A failure in one agent does not propagate silently as valid input to another. | Errors and hallucinations spreading across cooperating agents. | Fault injection at one agent; observe downstream handling. | OWASP T&M |
F07 | Multi-Agent Delegation & Communication | Agent-to-agent communication is limited to functional roles, with topology segmented to minimise reachability. | Any-to-any agent communication maximises blast radius from one compromise. | Attempt communication outside a permitted role pair. | OWASP T&M |
F08 | Multi-Agent Delegation & Communication | High-risk operations in a multi-agent system require verification by an independent agent or a human before execution. | A single compromised agent authorising a critical action unchallenged. | Attempt a high-risk operation with a single agent and confirm it is blocked. | OWASP T&M |
F09 | Multi-Agent Delegation & Communication | Every agent is assigned a trust zone - internal managed, third-party under contract, or public or unknown. Authority does not flow from a lower zone to a higher one, and cross-zone messages are validated at the boundary. | Implicit trust between agents that have different owners, controls and accountability. | Attempt a cross-zone instruction from a lower to a higher trust zone. | NPW; IMDA |
G01 | Human Oversight & Disclosure | The level of human involvement is defined per agent and matched to its tier. | Oversight either absent or applied uniformly regardless of consequence. | Agent Charter states the involvement level and matches practice. | IMDA |
G02 | Human Oversight & Disclosure | Escalation triggers are defined as a specific taxonomy rather than a blanket human-in-the-loop statement. | Undefined oversight defaults to no oversight. | Trigger list present and exercised in the pilot. | IMDA; NPW |
G03 | Human Oversight & Disclosure | Reviewers can see enough of the agent's reasoning and action history to make a substantive decision. | Approval becomes rubber-stamping. | Walk through the reviewer interface against a real decision. | OWASP T&M |
G04 | Human Oversight & Disclosure | People interacting with an agent are told they are interacting with an AI system at first contact, on request, and persistently in the interface. | Trust exploitation; disclosure obligations under the EU AI Act and comparable rules. | Disclosure present at first interaction and on request. | EU AI Act; NPW |
G05 | Human Oversight & Disclosure | Reviewer workload and approval rates are monitored; approval rates approaching 100 per cent are investigated. | Automation bias hollowing out the control. | Approval rate metric reported to the governance forum. | IMDA; OWASP T&M |
G06 | Human Oversight & Disclosure | Agent outputs presented to people carry uncertainty or confidence signalling where the tier warrants it. | Overtrust in confidently stated but unverified output. | Output sample review. | NPW |
G07 | Human Oversight & Disclosure | Approval requests to human reviewers are rate-limited per reviewer and distributed across the reviewer pool. | Deliberate or accidental flooding producing rubber-stamped approvals. | Generate a burst of requests; confirm throttling and distribution. | OWASP T&M |
G08 | Human Oversight & Disclosure | Agents interacting with people do not adopt a human persona, do not deny being an AI system when asked, do not render links or attachments the person did not request, and cannot make binding commitments outside their declared action-space. | Trust exploitation - the agent used as the delivery mechanism for social engineering. | Ask the agent directly whether it is an AI; attempt to elicit a link and a commitment. | OWASP T&M; NPW |
H01 | Observability & Audit | Every agent action is logged at the finest granularity the platform supports. | Decisions cannot be reconstructed after an incident. | Log sample against a known action sequence. | TC260; OWASP T&M |
H02 | Observability & Audit | Logs capture tool calls, data accessed, external transmissions, permission changes and errors. | Partial logging that omits the fields forensics needs. | Field completeness check against the defined schema. | TC260; OWASP T&M |
H03 | Observability & Audit | Logs are immutable, cryptographically signed, and retained for a period defined by tier. | Log tampering by a compromised agent; evidence expiring before it is needed. | Immutability and retention configuration review. | OWASP T&M |
H04 | Observability & Audit | Any agent action can be traced to both the agent identity and the authorising principal. | Accountability opacity. | End-to-end trace test. | OWASP T&M |
H05 | Observability & Audit | Behavioural baselines are established per agent and deviation alerts configured. | Goal drift and rogue behaviour going unnoticed. | Induce a deviation and confirm the alert. | OWASP T&M |
H06 | Observability & Audit | The registered agent inventory is reconciled against observed activity at a defined interval. | The register drifts out of date within weeks. | Drift report showing registered against observed. | NPW |
H07 | Observability & Audit | Unapproved agents are actively discovered using network, endpoint, model-API and credential telemetry. | Agents nobody registered, operating with real permissions. | Discovery run record and disposition of findings. | TC260 |
H08 | Observability & Audit | An independent model audits agent behaviour for goal deviation, deceptive output and identity anomalies. | Misalignment and deception are not visible in conventional logs. | Introduce a known deviation and confirm the auditing model flags it. | OWASP T&M |
H09 | Observability & Audit | Tool invocation sequences are monitored for chains that circumvent policy and for abnormal execution frequency. | Individually permitted tool calls combining into a prohibited outcome. | Execute a known policy-circumventing chain in a test environment. | OWASP T&M |
H10 | Observability & Audit | Human overrides of agent decisions are logged, and actions denied then subsequently approved are flagged. | Approval shopping across reviewers or agents; suppressed refusals. | Deny an action, resubmit it, and confirm the discrepancy is flagged. | OWASP T&M |
I01 | Containment & Incident Response | Every agent has an emergency stop that halts execution mid-task. | No way to interrupt an agent once it has begun acting. | Execute the stop against a running task. | Five Eyes; OWASP T&M |
I02 | Containment & Incident Response | The emergency stop is tested at a defined interval and after any material change. | A control that exists in principle but has never been exercised. | Dated test record. | NPW |
I03 | Containment & Incident Response | A named owner is contactable for each agent at Tier 3 and above. | No responder when an agent misbehaves outside business hours. | On-call roster covering all in-scope agents. | NPW |
I04 | Containment & Incident Response | Agent incidents are classified under a taxonomy covering both safety and security failure modes. | Incidents that are neither a breach nor an outage fall between processes. | Taxonomy exists and has been applied to at least one case. | NPW |
I05 | Containment & Incident Response | Incident response includes agent-specific steps: credential revocation, memory quarantine and tool disconnection. | Standard IR does not remove agent persistence. | Playbook review and tabletop exercise. | OWASP T&M |
I06 | Containment & Incident Response | Near misses are recorded and reviewed alongside incidents. | The most informative events are the ones that caused no damage. | Near-miss register reviewed at the governance forum. | NPW |
I07 | Containment & Incident Response | A suspected rogue agent is isolated together with its memory and communication history, its privileges revoked, and attempts to rejoin under a new identity are detected. | Containment that leaves memory and credentials intact leaves the compromise intact. | Tabletop or live isolation of one agent, including re-entry detection. | OWASP T&M |
J01 | Lifecycle & Change Management | No agent is connected to internal data or systems without recorded approval. | Ungoverned deployment straight to production. | Approval record for every registered agent. | TC260 |
J02 | Lifecycle & Change Management | Every agent is entered in the Agent Registry, with all fields in the Agent Registry Schema completed and kept current. | You cannot govern what you cannot see. | Registry completeness check against the schema. | TC260; IMDA |
J03 | Lifecycle & Change Management | Model change, tool addition, action-space expansion, new delegation, incident or new counterparty triggers re-review. | Controls sized for an agent that no longer exists. | Trigger log with resulting re-reviews. | IMDA; NPW |
J04 | Lifecycle & Change Management | Agents are tested against tier-appropriate cases before deployment - injection, tool misuse, permission boundary and, where applicable, cascading failure. | Untested behaviour released into production. | Test evidence retained per release. | OWASP T&M |
J05 | Lifecycle & Change Management | Decommissioning removes credentials, authorisations, memory and third-party grants, and closes external access points. | Residual access and orphaned credentials after retirement. | Completed decommission checklist per retired agent. | TC260 |
J06 | Lifecycle & Change Management | Subscriptions and metered services associated with a decommissioned agent are cancelled and billing checked for anomalies. | Continuing cost and continuing access after shutdown. | Billing review following decommission. | TC260 |
J07 | Lifecycle & Change Management | Agents with no recorded activity for a defined period are reviewed for decommissioning. | Dormant agents retaining live permissions. | Dormancy report and disposition. | NPW |
J08 | Lifecycle & Change Management | Agents are red-teamed against simulated poisoned supply-chain components before deployment at Tier 3 and above. | Supply chain defences that remain untested until a real compromise. | Test evidence from a simulated poisoned component. | OWASP T&M |
J10 | Lifecycle & Change Management | Model versions and configuration are pinned per agent, evaluated against the agent's test protocol before adoption, and reversible to the previous version. | Silent behaviour change from a provider-side model update, with no rollback. | Confirm the pinned version matches deployed state; execute a rollback in test. | NPW; IMDA |
K01 | Continuity & Resilience | For the model and provider recorded in the Agent Registry, a documented and owned response exists for loss of that dependency - provider outage, model deprecation or withdrawal, or a change of commercial or licensing terms | A business process built on a dependency that can be withdrawn, degraded or repriced on the provider's timetable rather than the organisation's. | For each in-scope agent, a named owner and a documented response covering outage, deprecation and terms change. The response names a specific alternative, or records an accepted decision that the process stops. | NPW |
K02 | Continuity & Resilience | Agent output quality is monitored against a baseline, with alerting on degradation. | Silent quality decline after a model, prompt or data change, detected first by a customer. | Introduce a known degradation and confirm the alert. | NPW |
K03 | Continuity & Resilience | Every Tier 3 and Tier 4 agent has a defined fallback - a deterministic path, a manual process, or a documented acceptance that the process stops. | No route to complete the work when the agent is unavailable or has been stopped. | Fallback documented, owned, and exercised at least once. | NPW |
K04 | Continuity & Resilience | Concentration of agents on a single model, provider or orchestration platform is recorded and formally accepted. | A single provider incident taking out an unknown share of business processes at once. | Concentration report reviewed at the governance forum. | NPW |
K05 | Continuity & Resilience | Recovery from agent failure is tested at a defined interval, including restoration from a stopped or isolated state. | Recovery procedures that have only ever existed on paper. | Dated recovery test record. | NPW |
Catalogue version 2.4.0, published 12 September 2026. Control statements are licensed under CC BY-SA 4.0, reuse and adaptation are permitted with attribution, share-alike.
Control ID J09 was retired in a prior revision. IDs are not renumbered after publication, so existing assessments and citations referencing a control ID remain stable.
bottom of page