AI Agents in the Cloud: A Risk Management Framework for Security Leaders

Your risk committee meets Thursday. The agenda has a new item: AI agent risk posture. You open the register. The fraud detection agent shipped in March is on it. So is the customer service agent. Neither row is useful — “likelihood: medium, impact: high, control: service account scoped via IAM.” Three months ago that was approximately right. Last week the platform team added two MCP connections, the model was upgraded, and the agent now touches data classes the entry never anticipated.

The Gravitee State of AI Agent Security 2026 reports that 80.9% of teams have moved into active testing or production while only 14.4% have full security approval for their fleet — and 88% have already had confirmed or suspected incidents. The U.S. Treasury’s February 2026 Financial Services AI Risk Management Framework gives regulators maturity criteria for grading AI agent security programs. The board is asking. The register can’t answer.

The fix is to stop building the register around what the agent does. Behavior is non-deterministic; what behavior happens on is not. Every cloud-deployed AI agent has four risk surfaces — Identity, Data, Tool, Model — and they hold their shape across model upgrades, prompt changes, and new MCP connections. This article is the program-level framework that runs from those four surfaces: a risk register that survives non-determinism, a Likelihood × Impact methodology that uses observable inputs instead of subjective ratings, and three runtime-derived KRIs your risk committee can read every month.

Four Risk Surfaces Stay Stable Even When Agent Behavior Doesn’t

Traditional risk registers depend on three assumptions: that you can name the threat, scope the impact, and describe the control. AI agents violate all three. The threat is whoever wrote the data the agent retrieved at inference time. The impact shifts with which tools were available when the prompt arrived. The control was scoped to declared permissions, not what the agent actually exercised.

What stays stable is the surface. Behavior is non-deterministic; what behavior happens on is not. Every cloud-deployed AI agent has exactly four risk surfaces, and they hold their shape regardless of which prompt arrives or which tool gets added next sprint.

Identity surface. The credentials, scoped permissions, IAM bindings, and federated identity context the agent operates under. This is where lateral reach lives, and the boundary of the agent’s identity doesn’t shift when the agent’s behavior does.

Data surface. The datasets the agent reads, the sensitivity classes it can touch, the egress destinations it can reach. Tomorrow’s data transformations are unknown; today’s deployment configuration is not.

Tool surface. The APIs and MCP tool servers the agent can invoke. Which specific tool gets called in any one execution is non-deterministic; which tools are wired into the agent’s tool catalog is configuration.

Model surface. The model artifact and version, the prompt template family, the output channels feeding downstream systems. Outputs vary; the model and the channels do not.

Register rows that sit at (agent × surface) survive prompt changes, model upgrades, and tool additions. Rows keyed to specific behaviors do not. Each surface also resolves one broken assumption — Identity bounds lateral reach, Data and Tool bound impact, Model bounds output channels — with no claim about which specific behavior triggers them.

Identify Every Agent and Map It to Four Surfaces

Your risk program’s first artifact is the register. Its first failure mode is familiar from cloud-native security: declared inventory misses workloads that exist at runtime. AI agents amplify it — Trend Micro identified over 10,000 unprotected AI model servers exposed online before they showed up on a CMDB.

Runtime-derived discovery solves this. A runtime AI Bill of Materials enumerates running agent processes, the model endpoints they call, the network connections they open, and the API patterns they follow — whether or not anything was declared. The enumeration populates the register’s first column.

For each agent, populate four columns. Identity: service account or workload identity, federated bindings, the union of permissions granted across all sources. Data: every dataset, database, and bucket the agent’s identity can reach, classified by sensitivity. Tool: the catalog of APIs and MCP tool servers the deployment exposes — including new ones added since the last review. Model: the model artifact and version, prompt template family, and output destinations.

The four-column row is the unit of register maintenance. A model upgrade changes only the Model column; a new MCP connection changes only the Tool column. The row stays valid; specific cells get updated. Rows keyed to specific behaviors require full rewrites every time the agent encounters new context.

Score Likelihood × Impact Without 1-to-5 Subjective Ratings

Risk methodologies built for traditional workloads use 1-to-5 subjective ratings on likelihood and impact. They work for predictable workloads, where two analysts roughly agree on the numbers. AI agents punish that ambiguity — two analysts looking at the same agent produce ratings two tiers apart, each compensating for non-determinism with intuition. The fix is to make the inputs concrete, observable, and surface-anchored.

Likelihood = Exposure × Autonomy × Instrumentation Gap

Exposure classifies where the agent runs in three values: internet-facing (processes data from the open internet, including indirect prompt injection vectors), internal-only (data origin bounded by VPN or internal network), or closed-network (no external data ingestion). Threat-actor-based likelihood breaks for AI agents because indirect prompt injection makes the threat actor random data on the public internet. Exposure substitutes.

Autonomy is a five-tier scale: from read-only retrieval-augmented agents at one end, through tool-using agents that wait for human confirmation, to fully autonomous workflow agents at the other. Five tiers gives enough resolution without false precision. The AI workload security buyer’s guide describes the taxonomy in detail.

Instrumentation Gap is the ratio of observed-to-blind for the agent’s behavior, per surface. If runtime telemetry covers Identity and Tool surfaces but not Model output channels, the gap is measurable. This input is what turns runtime instrumentation from a tooling preference into a likelihood input — without it, likelihood collapses to “we don’t know.”

Impact = Identity Blast Radius + Data Sensitivity + Tool Capability + Model Reach

The four impact dimensions map directly to the four surfaces. Identity Blast Radius: the IAM scope and lateral-movement reach of the agent’s identity. Data Sensitivity: the highest classification the Data column touches. Tool Capability: whether the Tool column contains destructive operations (write, delete, execute) or only read-only ones. Model Reach: the count and criticality of downstream systems consuming the output.

Sum the impact dimensions, multiply by the likelihood factors, classify into four tiers — Critical, High, Moderate, Low — by score thresholds you set once. This supplies the cloud-agent-specific Measure inputs the NIST AI Risk Management Framework leaves open. Two analysts scoring the same agent reach the same tier, because the inputs are observable deployment properties, not probability judgments.

Match Each Risk Classification to One Treatment Option

The ISO 31000 treatment vocabulary — avoid, transfer, mitigate, accept — applies, but each option needs an agent-specific definition first.

Avoid. Don’t deploy this agent. Replace the use case with deterministic automation, or drop the use case. For Critical-classified agents where the risk surfaces are too broad to mitigate, this is sometimes the right answer — the risk committee deserves to see it as a real option.

Transfer. Use a managed agent service where the vendor owns the runtime, with residual liability shifted via business associate agreement, data processing agreement, or contractual indemnification. The risk doesn’t disappear; it moves to a counterparty whose runtime controls become part of your due diligence.

Mitigate. Deploy runtime controls that constrain how the agent uses its surfaces. This is observe-to-enforce: build baselines from observed behavior, then progressively enforce policies derived from them. For Critical agents in regulated environments, pre-enforced deployment builds baselines in staging before production, validating against parity criteria before enforcement goes live.

Accept. Document residual risk after mitigation, sign acceptance, and monitor via KRIs. Acceptance is the risk-committee artifact most often skipped — and the one that creates the cleanest audit trail when an incident happens.

The classification-to-treatment map:

Classification	Treatment options	Typical signal	Risk-committee artifact
Critical	Avoid OR Transfer OR Mitigate via pre-enforced deployment	Internet-facing + high autonomy + destructive tool capability + sensitive data	Executive-signed risk decision; pre-enforced deployment evidence if mitigated
High	Mitigate via observe-to-enforce + per-agent guardrails	Sensitive data access OR destructive tool capability, with observability in place	Mitigation plan; baseline + enforcement evidence
Moderate	Mitigate (standard) + monitoring	Bounded data sensitivity, read-mostly tool capability, internal exposure	Standard control evidence; KRI subscription
Low	Accept + KRI monitoring	Closed-network, low autonomy, read-only, public/non-sensitive data	Signed acceptance; quarterly KRI review

Within Mitigate, treatment differs by surface. Identity: scoped permissions and credential rotation. Tool: allowlisting and rate constraints. Data: egress controls and field-level access policies. Model: output validation and downstream-system gating. The treatment plan is the union of these surface-specific controls — not a single “deploy a security platform” line item.

Track Three Runtime KRIs Your Risk Committee Will Actually Read

Key risk indicators are the metrics a risk committee reads month over month. For AI agents, three KRIs do load-bearing work — and all three depend on runtime instrumentation. Without runtime data, you produce posture-scan KRIs that look like AI risk indicators but measure configuration drift, not agent risk.

KRI 1: Behavioral baseline deviation rate (Tool and Model surfaces). The percentage of agent executions in the monthly review window that fall outside the behavioral baseline — tool invocation patterns, output channel activity, sequence variations. A flat or declining rate is healthy; a step change, a leading signal. The metric requires per-agent baselines built from observed behavior; a generic anomaly score doesn’t distinguish “this prompt is unusual” from “this agent is being coerced.”

KRI 2: Permission entropy (Identity surface). The drift between declared scope (the union of all permissions granted to the agent’s identity) and observed scope (the subset actually exercised), computed monthly. A widening gap means the agent has accumulated permissions it doesn’t use — dormant attack surface that becomes active the moment the agent is coerced. This is the cleanest form of runtime-informed posture as a continuously refreshed register entry.

KRI 3: Cross-agent correlation rate (cross-surface, multi-agent). The frequency with which behavioral signals on one agent correlate with signals on another in a way that suggests contagion — shared compromise vectors, lateral movement through shared identities, prompt injection cascading across delegation chains. Multi-agent orchestrations need this signal most and produce it least often, because it lives in cross-layer detection, not within any single product.

None of these come from configuration scanning, posture management alone, or alert-counting — they require runtime telemetry across the four surfaces. Threshold-setting is environment-specific: anchor each KRI to its baseline period (a quarter is workable), and define escalation in advance — SOC ticket on minor breach, risk-committee flag on sustained breach, board-reporting line on Critical-tier breach.

Where to Start

Start with the surface-mapping exercise: take the top three agents on your current register and rebuild their rows around (agent × four surfaces). Score them with the Likelihood × Impact methodology. Pick treatment options. Define the three KRIs. The next quarterly risk committee should see a register that answers the question — not one that asks for an extension.

Making the four surfaces observable, scoring inputs measurable, and KRIs continuous requires runtime instrumentation. ARMO’s cloud-native security for AI workloads delivers that layer; book a demo to walk the framework against your environment.

Frequently Asked Questions

How often should the AI agent risk register be reviewed? Different cadences for different layers. Surface-level reviews are quarterly. KRI monitoring is monthly, in line with risk committee cadence. Classification-level reassessment runs on triggering events: major model upgrade, new tool connection, autonomy tier change, or material change in the data accessed.

Who owns the AI agent risk register? The CISO or AI governance lead owns the artifact; the platform team running the agents owns the runtime data feed. The CISO sets methodology and thresholds; the platform team produces observed data; the risk committee reads consolidated KRIs.

What’s the relationship between this and the per-agent go-live checklist? Different decisions, different artifacts, both required. The per-agent gate is one binary decision before a specific agent ships. The risk register is continuous portfolio management across every agent in production — including residual-risk monitoring for agents the gate already approved.

Can we use our existing GRC platform? Yes for register storage and treatment workflow — any modern GRC platform handles those. The runtime-derived KRIs need integration with the runtime detection layer; most GRC platforms accept them via API, with the runtime layer pushing updates on the schedule the committee reads.

What’s the minimum runtime instrumentation needed to make the KRIs work? Three things: per-agent behavioral baselining (for KRI 1), observed-vs-declared permission analysis (for KRI 2), and cross-layer correlation across cloud, Kubernetes, and application telemetry (for KRI 3). Configuration scanning produces none of them.