Cloud Infrastructure Governance

Your agents operate the cloud. Your governance doesn't.

AI agents now operate cloud infrastructure directly: assuming IAM roles, enumerating storage, querying instance metadata endpoints, and executing inside Kubernetes. The same blast radius that let an attacker reach a metadata endpoint and walk out with 106 million records now belongs to an autonomous agent that can do it at machine speed and without a human in the loop. IAM policies and network controls decide what an identity can do. Nothing governs what the agent should do across IAM, storage, metadata, and Kubernetes, and nothing produces a tamper-evident record of what it did.

Self-hosted by design. Bring your own model, bring your own key -- your cloud credentials + action history stays in your infrastructure. Agentomy never proxies, never hosts, never sees the data plane. sovereignty model →

5
Cloud detection methods
4
Coverage areas
20
GovernanceBench scenarios
38
Behavioral monitor methods
sub-50ms
Fleet halt response

Cloud security watches the configuration. No one governs the agent's behavior.

In 2019, an attacker exploited a server-side request forgery flaw to reach the EC2 instance metadata endpoint at 169.254.169.254, retrieved the credentials of an over-permissioned IAM role, and used them to enumerate and exfiltrate storage holding the records of over 100 million people. Every step in that chain is now an action an autonomous agent can take on its own: probe metadata, assume a role, list buckets, read objects, exec into a pod.

Cloud security posture management, cloud infrastructure entitlement management, and cloud-native application protection tools inventory misconfigurations and over-broad entitlements. They tell you what an identity is permitted to do. They do not tell you whether this agent, right now, should be probing the metadata endpoint, escalating an IAM role, or enumerating every bucket in the account, and they do not produce a hash-linked record that survives the agent re-registering. Agentomy governs the behavioral layer above IAM and the network.

5 cloud-specific detection methods mapped to real cloud attack chains

Cloud governance adds five cloud-specific detectors to the behavioral monitor. The monitor includes 9 core methods available in every deployment and 31 vertical-specific methods (including these 5 cloud-infrastructure detectors) with fleet infrastructure. The full 40-method monitor runs continuously across the cloud agent lifecycle. Each detector references a concrete cloud operation, not a generic anomaly score.

CLOUD-001
IMDS / Metadata Probing
Agent access to the instance metadata endpoint (169.254.169.254 and equivalents). This is the exact step that converted a server-side request forgery into stolen IAM credentials in the Capital One breach. The detector flags metadata access and records the requesting agent, target host, and request URL.
Critical
CLOUD-002
Storage Enumeration
Excessive enumeration of cloud storage (bucket and object listing) beyond an agent's established baseline. Catches the reconnaissance pattern that precedes mass data exfiltration, where an agent or compromised credential walks the entire storage namespace before reading objects.
High
CLOUD-003
IAM Privilege Escalation
Cloud identity operations that expand privilege: AssumeRole into higher tiers, CreateAccessKey, policy attachment, role chaining. The detector flags escalation attempts against the agent's authorized scope and tier, catching the move from a read-only foothold to administrative reach.
Critical
CLOUD-004
Cloud Credential Exfiltration
Cloud credential patterns appearing in an agent's output or response stream (access keys, session tokens, secrets). Catches the case where a governed agent surfaces credentials it should never emit, whether through prompt injection, tool misuse, or a misconfigured response.
Critical
CLOUD-005
Kubernetes API Abuse
Dangerous Kubernetes operations: pod exec, privileged container creation, secret access, and cluster-role binding. Catches the container-escape and lateral-movement primitives an agent with cluster API access can invoke, and gates them against the agent's tier.
Critical

Governed by the same core that governs every agent

Cloud agents are not a separate product. They are governed identically to every other agent -- an agentId with an action, a scope, and a tier -- through the same authorization, audit, halt, and behavioral engine. That is the point: one governance core, one audit trail, one kill switch, whether the agent is trading, driving, or operating a cloud account. GovernanceBench Suite 13 exercises the four coverage areas below against the live governance layer.

Tier-Based Authorization
Every cloud action is authorized against the agent's tier and scope before it executes. Read-only agents cannot perform IAM operations, access storage outside scope, or exec into Kubernetes. Permitted reads pass; escalation is blocked.
Hash-Linked Audit Trail
Credential access, IMDS probes, and storage enumeration each produce a tamper-evident, hash-linked audit block. Action history is retrievable per agent and survives the agent re-registering. Denials are logged, not just failures.
Fleet Halt
A single halt blocks subsequent cloud operations across the governed fleet, returns the affected agent count, and persists an audit ID for forensic reconstruction. Resume restores operations. Empty or unauthorized halt requests are rejected.
Behavioral Monitoring
The 5 cloud detectors run inside the behavioral monitor. Scope drift from a read-only baseline to admin is blocked, credential patterns in output are detectable, and quarantined cloud agents cannot execute further actions without operator release.

Mapped to the frameworks that govern cloud workloads

Agentomy maps governance controls to 10 compliance frameworks, 7 at self-assessed readiness; the ones below are the most directly relevant to cloud workloads. All mappings are internal self-assessments of readiness, pending external validation. Cloud-specific control catalogs (CSA CCM, ISO 27017) are applicable to this vertical but are not yet individually mapped. A FedRAMP authorization requires a federal agency sponsor and a 3PAO assessment and has not been initiated.

Framework Status Scope
NIST SP 800-53 (FedRAMP baseline) Self-assessed readiness NIST SP 800-53 Rev. 5 is the control baseline that underlies FedRAMP. The AC, AU, IR, and SI families map to agent authorization, the hash-linked audit trail, incident containment, and continuous monitoring. A FedRAMP authorization (ATO) is a separate federal process requiring an agency sponsor and a 3PAO assessment, and has not been initiated.
SOC 2 readiness Self-assessed readiness Trust services criteria for cloud and SaaS providers. Logical access controls, change management, and monitoring evidence supported by per-agent authorization decisions and retrievable action history.
ISO 27001 Self-assessed readiness Information security management. Access control (A.9), logging and monitoring (A.12), and operations security supported by tier-based authorization and tamper-evident audit blocks.
PCI DSS Self-assessed readiness Cardholder data environments increasingly run in cloud. Restricting access by business need-to-know and tracking all access to data and network resources maps to scope-bounded authorization and audit logging.
GDPR Self-assessed readiness Where cloud storage holds personal data, enumeration and exfiltration detection plus an auditable record of access support breach detection and accountability obligations.

Stolen metadata credentials, exposed storage, and leaked secrets

These were human attackers and misconfigurations. The relevance to agent governance is direct: an autonomous agent operating cloud infrastructure inherits the same credentials and the same blast radius, and it acts faster and without a human pausing to ask whether the action is appropriate.

Capital One, July 2019
106M records via SSRF to instance metadata
A server-side request forgery flaw was used to reach the EC2 metadata endpoint, retrieve the credentials of an over-permissioned IAM role, and enumerate and exfiltrate storage holding records of over 100 million people in the US and Canada. The OCC imposed an $80M penalty in 2020. The metadata-to-IAM-to-storage chain is the canonical cloud breach path.

Maps to: IMDS Probing, IAM Privilege Escalation, Storage Enumeration

LastPass, Aug-Nov 2022
Cloud storage keys used to exfiltrate vault backups
A threat actor obtained cloud storage access keys from a compromised engineer endpoint and used them to access and copy backups from cloud object storage, including customer vault data. A valid credential plus unmonitored storage access was sufficient. Behavioral governance over storage enumeration and credential use targets exactly this path.

Maps to: Cloud Credential Exfiltration, Storage Enumeration

Microsoft AI Research, Sept 2023
38TB exposed via over-permissioned storage token
An over-permissioned, long-lived storage access token attached to a public bucket exposed 38TB of internal data, including secrets and credentials. Disclosed by Wiz. Demonstrates how a single over-broad cloud credential and unmonitored storage scope turns into mass exposure, the scenario agent-level scope enforcement is designed to contain.

Maps to: Storage Enumeration, Cloud Credential Exfiltration, IAM Privilege Escalation

Posture and entitlements are covered. Agent behavior is not.

CSPM tools find misconfigurations. CIEM tools map and right-size entitlements. CNAPP suites bundle scanning, workload protection, and posture. All of them answer what an identity is allowed to do. None of them govern, in real time, whether this agent should be probing the metadata endpoint, escalating an IAM role, or enumerating every bucket, and none produce a tamper-evident behavioral record per agent. Agentomy governs the controller, not the configuration.

Four entry paths to governed cloud agents

Govern cloud agents through whichever surface fits your stack. Gate mode authorizes a cloud action before it executes. Observer mode records and monitors after the fact. Both modes produce the same hash-linked audit trail.

API
REST API
Standard HTTP endpoints for any cloud agent runtime. Pre-action authorization, action logging, fleet halt, and audit queries. Platform-agnostic across AWS, Azure, and GCP agents.
SDK
TypeScript / Python / Go
First-class SDK adapters for cloud agent frameworks. Wrap IAM, storage, metadata, and Kubernetes calls with authorization and audit. Go edge binary for self-contained deployments.
CLI
Command Line Interface
Governance operations from the terminal. Emergency halt, audit export for compliance evidence, and benchmark execution. Scriptable for CI/CD and incident response automation.
CLW
Cloud-Infra Variant
The cloud-infra governance variant scopes authorization to cloud actions: IAM, storage, metadata, monitoring, and Kubernetes. The same agentId / action / scope / tier model, tuned for cloud operations.

20 cloud governance scenarios. Run it yourself.

Suite 13: Cloud Infrastructure Governance. 20 self-contained, idempotent scenarios across 4 coverage areas: cloud agent authorization (5), cloud action audit trail (5), cloud fleet halt (5), and cloud behavioral monitoring (5). Every scenario runs against the live governance layer using the same authorization, log, halt, and status endpoints. No mocks. No stubs.

# Run the cloud infrastructure governance benchmark $ npx agentomy-bench --suite cloud-infrastructure # Export results for compliance evidence $ npx agentomy-bench --suite cloud-infrastructure --export json

What we are and what we are not

Three commands to governed cloud agents

# Install the governance adapter $ npm install @agentomy/governance # Authorize a cloud agent IAM action (pre-action gate) $ curl -X POST http://your-agentomy-instance:3000/api/claw/authorize \ -H "Content-Type: application/json" \ -H "X-API-Key: YOUR_API_KEY" \ -d '{"agentId": "cloud-agent-01", "tier": 1, "action": "AssumeRole", "scope": "iam", "clawVariant": "cloud-infra"}' # Emergency halt -- all governed cloud agents $ curl -X POST http://your-agentomy-instance:3000/api/claw/halt \ -H "Content-Type: application/json" \ -H "X-API-Key: YOUR_API_KEY" \ -d '{"reason": "IMDS probing detected", "operatorId": "cloud-ops-01"}'

Govern your cloud agents before their credentials govern you.

Autonomous agents are assuming IAM roles, reading storage, and querying metadata endpoints today. The behavioral governance layer that decides whether they should, and proves what they did, is the gap. Run the 20-scenario benchmark against your governance layer and see.

Request Access