ISO 27001 for agentic AI
Yes. Clause 6.1.3 requires organizations to determine controls from their own risk assessment, using Annex A as a reference baseline, and agents are exactly the kind of risk that triggers it. An agent is an asset to inventory under A.5.9, an identity to manage under A.5.16, and an application to monitor under A.8.16. No new framework and no second audit is required. What changes is the enforcement point the controls assume, which moves from the network perimeter and the database grant to the tool call an agent makes on an employee’s behalf.
During our recent ISO 27001 assessment, we identified specific gaps in our AI control framework. This year we don't have to call that out, but starting next year we will. It's a big wake-up call, and we're implementing controls ASAP.
Every year, certified companies run the same ISO 27001 exercise: update the risk assessment, walk the assessor through the evidence, and renew the certificate. This cycle is the first since enterprises adopted AI at scale, and audits are beginning to surface the compliance gaps that adoption created.
AI is the largest shift in enterprise IT since the cloud migration. Cloud was a top-down program that IT planned and ran over years. AI came in through individual employees instead, in about a year. Engineers installed coding agents, teams wired assistants into internal systems, and almost none of it passed through procurement or landed in an asset register. Companies are now discovering that they are no longer compliant.
This page maps the ISO 27001 requirements to AI agents: the fourteen Annex A controls that agent adoption touches, what each requires, and what an implemented control looks like in practice.
None of it requires a new framework or a second audit. Clause 6.1.3 already directs organizations to determine controls from their own risk assessment, using Annex A as a reference baseline, and agents are exactly the kind of risk that triggers it. An agent is an asset to inventory under A.5.9, an identity to manage under A.5.16, and an application to monitor under A.8.16.
What moved is the enforcement point every one of those controls assumes. It is no longer the network perimeter or the database grant. It is the tool call an agent makes on behalf of an employee.
The Speakeasy AI Control Plane sits at that enforcement point. Agents reach tools through Speakeasy-hosted Model Context Protocol (MCP) endpoints, where calls are authorized, dispatched, and logged. Coding agents on employee machines are governed at the hook boundary, in the moment before their harness executes a tool call. This reference architecture turns the fourteen controls below from awkward audit conversations into demonstrable implementations.
The fourteen controls at a glance
For each control, the table below covers what the clause requires, what agents change about it, and how the control plane implements it across set-up, runtime, and the evidence an assessor receives.
Annex A controls, re-answered for agents
A.5 Organizational controls
Governance, inventory, identity, supplier, and incident controls: the clauses that define what an organization knows about its agents and who is accountable for them.
A.5.3 Segregation of duties
Organizational
What the control requires
Conflicting duties and conflicting areas of responsibility must be identified and separated, so no single actor can initiate, approve, and execute a high-risk operation alone. The purpose is to prevent fraud, error, and the bypassing of controls by making sensitive chains of activity require more than one pair of hands. Where full separation is impractical, compensating controls close the gap.
What changes with agents
An autonomous agent can concentrate an entire risk chain into one process: it reads untrusted input, holds credentials, accesses sensitive data, and commands an outbound channel. That combination, sometimes called the lethal trifecta, is a segregation-of-duties failure executing at machine speed. The control now has to be applied inside a single agent's workflow, not just across people.
What the implementation looks like
An implemented control breaks the chain in three places. Content policies evaluate every tool call before it executes, blocking the categories that must never cross the boundary and holding judgment calls for explicit human acknowledgement. Credentials are split so no single agent configuration holds both sensitive-data access and a privileged outbound channel. Exceptions flow through an approval workflow, so a second person enters the chain exactly where the standard expects one.
How Speakeasy implements the control
Set up
- Write risk policies for the categories that must not cross the boundary: secret detection (Gitleaks rulesets), PII detection (Presidio, with configurable entity types), and custom rules. Set action
blockwhere the chain must not complete andwarnwhere a human judgment call suffices. - Target the policies. Audience scoping applies a policy to everyone, or to the specific principals whose agents combine untrusted input with privileged tools.
- Split the credential chain. Give each toolset its own Environment, so no single agent configuration holds both sensitive-data access and privileged egress credentials.
At runtime
- Enforcement runs at the coding-agent hook boundary in Claude Code, Cursor, Codex, and the unified path for OpenCode. A
blockreturns a denial before the harness executes the tool call. Awarnwithholds the exact call until the same user explicitly acknowledges it, through a one-shot link valid for 10 minutes, with a 5-minute grace window for the identical retry. - Human approval enters the chain through the bypass workflow. A requestable block mints a request-access link, valid for seven days, that opens a pending request an organization admin must approve, deny, or later revoke in Approval Requests.
Evidence
- Denials, warn acknowledgements keyed to a SHA-256 fingerprint of the exact call, and every approve, deny, and revoke decision are individual audit events. Detected sensitive values are stored masked.
A.5.9 Inventory of information and other associated assets
Organizational
What the control requires
The organization must develop and maintain an inventory of information and its associated assets, meaning systems, services, and anything else that stores, processes, or can affect information, with a designated owner for each entry. The inventory must be accurate, kept up to date, and cover the lifecycle of an asset from onboarding to disposal, because you cannot protect, classify, or risk-assess what you have not recorded.
What changes with agents
Agents, their tools, their MCP servers, and the sub-agents they spawn are a new asset class the register was never designed to hold. Anyone can wire an MCP server into an editor in minutes, and a coding agent can spawn ten sub-agents invisibly. Auditors are beginning to ask where the agents are on the A.5.9 register, and most organizations cannot answer.
What the implementation looks like
An implemented control is a register that maintains itself. Agents reach tools through a system that records every agent, tool, MCP server, and owner as a side effect of use, devices enroll against named users, and unsanctioned servers are discovered from live traffic rather than waiting to be declared. Point-in-time snapshots preserve what the approved surface was on any given date.
How Speakeasy implements the control
Set up
- Register every upstream as a Source, whether an OpenAPI document, a Function, or a remote or tunneled MCP server, then publish curated toolsets from it. The registry records the full capability surface per agent: which tools, from which source APIs, against which Environments, with ownership carried by organization and project structure.
- Enroll coding agents through the device flow. A session-authorized, single-use enrollment code, using PKCE S256 and valid for 5 minutes, is consumed atomically and binds each device to a named user.
At runtime
- Hook telemetry correlates every event to the enrolled user, the device by serial and hostname, and the harness that produced it. That is an activity-based inventory of what actually runs, not what was declared.
- Shadow MCP inventory aggregates the MCP server identities and URLs observed in employee agent traffic, with use counts, attributed to user and hook source. Unsanctioned and SaaS-embedded servers surface on the register instead of around it.
Evidence
- Completed Deployments are append-only snapshots, so the sequence of them is a point-in-time record of the approved capability surface over time. Inventory queries and the audit trail show who changed it and when.
For vetting a candidate server before it joins the register, the control plane ships assessment components: registry provenance covering official status, lifecycle, and publish history; npm and PyPI package metadata including license and maintainers where the registry exposes them; and capability scoring from tool annotations and schemas. These fold into an intake review rather than replacing it.
A.5.10 Acceptable use of information and other associated assets
Organizational
What the control requires
Rules for the acceptable use and handling of information and associated assets must be identified, documented, and implemented. Everyone using organizational assets, employees and third parties alike, must know what is permitted, and the rules must actually be put into effect rather than existing only as policy text.
What changes with agents
Shadow AI is shadow IT at agent speed: any employee can connect an unvetted MCP server or agent to company data before lunch. An acceptable-use PDF discovers nothing and prevents nothing. The control is only real if unsanctioned agents are actively found and the rules are enforced at the point of use.
What the implementation looks like
An implemented control turns the acceptable-use policy from a document into a default. The organization picks a disposition, default-deny with an allowlist or default-allow with a blocklist, enforces it at the point of use, and shows the user the rule they tripped at the moment they trip it. Discovery runs continuously, because a policy that cannot see unsanctioned use cannot govern it.
How Speakeasy implements the control
Set up
- Choose the Shadow MCP disposition that matches the policy:
block_all, the product default, which is default-deny with a managed allowlist and per-server bypasses, orallow_all, which is default-allow with a blocklist and one-click block and unblock per server. - Put the acceptable-use language into the policy itself. Block and warn responses render a custom message, with template variables (
%{match},%{entity},%{policy},%{rule}) so the user sees exactly what tripped and why.
At runtime
- Device hooks enforce the disposition inside Claude Code, Cursor, Codex, and OpenCode sessions. A non-approved MCP server is denied at the hook boundary, with the custom message and, where allowed, a request-access link.
- The account-identity scanner asynchronously flags AI accounts registered on non-approved email domains from captured session attribution. It is flag-only by design: it surfaces, humans decide.
Evidence
- The Shadow MCP inventory with per-user attribution is the evidence that discovery is operating. Block and unblock actions and disposition changes are audit events.
A.5.16 Identity management
Organizational
What the control requires
The full lifecycle of identities must be managed, for people and for non-human entities such as services and devices. Each identity must be unique and attributable to a single entity, issued through a defined process, and promptly modified or revoked when circumstances change. Shared identities are the exception, justified and documented, never the default.
What changes with agents
Agents accumulate long-lived API keys pasted into config files, or arrive with vendor-managed standing credentials the deployer cannot rotate or revoke. An identity your infrastructure did not issue and cannot kill is an identity-management failure waiting for its incident, and agents multiply those identities faster than any joiner-mover-leaver process.
What the implementation looks like
An implemented control gives every agent an identity the organization issued and can kill. Human identities come from the corporate directory, agent credentials are scoped and revocable keys issued through a defined process, and downstream secrets live in encrypted stores rather than config files. Issuance and revocation leave a record, and every action an agent takes attributes back to a single named entity.
How Speakeasy implements the control
Set up
- Connect the identity provider through WorkOS-managed SAML and OIDC connections, with Okta and Entra ID among the supported directories, and Directory Sync driving organization membership and roles.
- Issue scoped API keys where machine access is needed. Key bodies are 32 cryptographically random bytes, only the SHA-256 hash and a short prefix are stored, and the raw value is shown exactly once. Per-user
agent_userkeys are deliberately narrow: the token-exchange path that mints them accepts only the broader org install credential, so a leaked agent key cannot mint another. - Store downstream API credentials in Environments, encrypted at rest with AES-256-GCM.
At runtime
- MCP client authorization runs OAuth-style flows with PKCE, consent, refresh, and revocation. Credentials are merged server-side from source to toolset to attached environment, then injected into each dispatched call. Stored secret values are not returned through normal reads.
- Coding-agent devices enroll via the single-use PKCE S256 code exchange, valid 5 minutes and consumed atomically on redemption, yielding a per-user, per-device key.
Evidence
- Key creation and revocation are audit events, and every tool call and hook event carries the user and key attribution that the “attributable to a single entity” requirement demands.
For organizations that must hold their own key material, feature-gated external signing keys let the control plane sign tokens with RS256 or ES256 keys living in an AWS KMS or Google Cloud KMS account, so the signing key lifecycle stays with the customer. This is token signing, not storage encryption.
A.5.19 Information security in supplier relationships
Organizational
What the control requires
Processes and procedures must be defined and implemented to manage the information security risks that come with using the products and services of suppliers: identifying which suppliers can affect your information, evaluating their security posture before use, and recording that evaluation in the vendor-risk process.
What changes with agents
An MCP server is a supplier with tool-level access to your systems, and most arrive from public registries with no vetting at all. Procurement review has to reach down to individual servers, packages, and models, not stop at the company logo on the contract.
What the implementation looks like
An implemented control extends vendor review down to the individual server. Each candidate MCP server gets an intake assessment covering registry provenance, package metadata, and its declared capabilities, and the outcome lands in the same vendor-risk process that governs any other supplier. Declared capability is treated as a claim, verified by testing where the consequences warrant it.
How Speakeasy implements the control
Set up
- Fold the control plane assessment components into the supplier review for each candidate MCP server: registry provenance covering official status, lifecycle, and latest publish and update history; package metadata pulled from npm and PyPI including license, maintainers where the registry exposes them, and publish history; and capability assessment scored from the declared tool annotations and input schemas of the server.
- Treat declared capability as declared. The assessment reads what the server claims about itself, so pair it with your own testing for high-consequence suppliers.
At runtime
- Capability assessment feeds the destructive-tool scanner, so the risky declared operations of a supplier surface as findings during actual use.
Evidence
- Record the review outcome in the vendor-risk process. Approval and configuration actions in the control plane are audit events. On the other side of the table, Speakeasy presents its own supplier evidence: SOC 2 Type II and ISO 27001 certification.
A.5.24 Information security incident management planning and preparation
Organizational
What the control requires
The organization must plan and prepare for managing security incidents, with defined processes, assigned roles and responsibilities, and communication paths established before the incident, so that detection, containment, evidence collection, recovery, and post-incident learning follow a rehearsed procedure rather than improvisation.
What changes with agents
“Contain the agent” is a new runbook step. Without central control, incident responders hunt API keys across laptops while an autonomous process keeps executing. Agent-specific scenarios, including compromise via prompt injection, runaway execution, and data exfiltration through legitimate tools, need containment levers and evidence sources that exist in advance.
What the implementation looks like
An implemented control has the containment levers in place before the incident. The runbook names the exact actions that stop an agent: revoke its sessions and keys, disable its servers, and block the offending class of calls. The evidence needed afterward, meaning transcripts, tool logs, and change history, is collected continuously, and recovery is a redeploy of a known-good configuration.
How Speakeasy implements the control
Set up
- Write the agent runbook against the actual levers of the plane, and note their exact semantics. Revoking a user session invalidates its stored, hashed refresh token and revokes the access token where possible. Consents, remote sessions, and API keys revoke centrally. Directory deprovisioning removes organization membership and roles, so pair it with an explicit credential-revocation step, because it does not cascade to every session and key on its own.
- Subscribe the incident tooling to the typed audit-event webhooks, so agent events arrive in the process the team already operates.
At runtime (containment)
- Flip the relevant policy to
blockto stop a class of calls at the hook boundary, unpublish the affected MCP server org-wide, and revoke the keys and sessions of the actor. For cost-runaway scenarios, a breached spend rule with actionblockdenies further Claude Code, Codex, and Cursor agent events until the window resets.
Evidence and recovery
- Evidence is already collected: the audit trail with more than 170 event types and before-and-after snapshots on state-changing updates, session transcripts, and tool-call logs. Sensitive findings are stored masked, and unmasking one is itself an audited action.
- For recovery, redeploy a previous known-good Deployment. The clone carries a
cloned_fromlineage marker, so the rollback itself is traceable.
A.6 People controls
The humans who supervise, approve, and rely on agents, and what they need to know to do it safely.
A.6.3 Information security awareness, education and training
People
What the control requires
Personnel, and relevant third parties, must receive security awareness, education, and training appropriate to their function, with regular updates as the threat picture and organizational policies change. The training must be relevant to what people actually do, and the organization should be able to evidence that it happened and that it works.
What changes with agents
The manipulation target shifts from the inbox of an employee to their trust in a helpful agent. Staff who approve agent actions can be steered into harmful approvals, and approval fatigue quietly degrades human oversight into rubber-stamping. Awareness programs built for phishing have not caught up with either failure mode.
What the implementation looks like
An implemented control delivers the lesson at the moment of the risky action. A risky call pauses for an explicit, per-person acknowledgement that carries the teaching in its message, and each acknowledgement is recorded against the person and the exact action. Reviewer workload is also measured, because oversight that degrades into rubber-stamping is the failure mode this control exists to catch.
How Speakeasy implements the control
Set up
- Configure
warnpolicies for the behaviors you want to coach rather than forbid, and write the teaching into the custom message of the policy. The user sees your words, with the triggering match rendered inline and capped at 120 characters, so there is context without a data dump.
At runtime
- The warn challenge is a genuine checkpoint, not a dismissable toast. The specific call stays denied until the same user opens the one-shot challenge link, valid for 10 minutes, and explicitly acknowledges it. The acknowledgement is bound to the fingerprint of that exact call, with a 5-minute grace window for the identical retry.
- Reviewers get a workstation with a measurable workload. The Approval Requests queue and access-request challenges are the basis for staffing the oversight function and setting response-time SLAs.
Evidence
- Every acknowledgement and every approval decision is an audit event, which is a record that the awareness intervention reached the person, per person, per policy. Watchdog groups rule-clustered signals by dominant team, so it is visible where coaching is needed. The curriculum itself remains yours to build.
A.8 Technological controls
Access, configuration, deletion, logging, monitoring, network, and environment-separation controls, enforced at the layer agents actually operate on: the tool call.
A.8.3 Information access restriction
Technological
What the control requires
Access to information and associated assets must be restricted in line with the access-control policy of the organization, on need-to-know and need-to-use terms, with access rights granted per the policy, enforced by the systems holding the information, and reviewed as roles and requirements change. Who can read, write, and execute what should be a deliberate decision, not an inherited default.
What changes with agents
An agent shipped with read-everything defaults will read everything. The vendor of the agent does not know that in your environment “update record” means payroll, and setup-time configuration alone cannot hold the line. Restriction has to be evaluated at the moment of each tool call, per tool, per tenant, per user.
What the implementation looks like
An implemented control replaces vendor defaults with deliberate selection. Each agent reaches a curated set of tools rather than everything its vendor shipped, grants are scoped down to individual tools and operation types, and credentials bind each toolset to exactly the systems and tenants it should touch. Restriction is then re-evaluated on every call, because setup-time configuration cannot hold the line alone.
How Speakeasy implements the control
Set up
- Curate toolsets as explicit sets of tool URNs, so the reachable operations of an agent are exactly what you selected and nothing inherited. Use variations to rename, re-describe, re-annotate, and tag tools, and expose narrowed MCP endpoints with exact-match tag filtering.
- Keep regulated servers private and narrow their RBAC.
mcp:connectgrants can be scoped to individual tools and to a derived disposition (read_only,destructive,idempotent,open_world). Two defaults are worth changing deliberately: the built-in member role ships with unrestrictedmcp:connect, and public servers skip the RBAC check. For A.8.3 scope, make servers private and replace the default grant with tool- and disposition-scoped ones. Blocked-connect exclusions can carve exceptions out of broad roles. - Bind each toolset to an Environment holding credentials for exactly the systems and tenants it should reach, following your data classification rather than developer defaults.
At runtime
- Private MCP connections are authorized at server scope, and every private
tools/callis re-authorized by tool, disposition, and project at dispatch time. Tenant-sensitive queries carry organization and project predicates.
Evidence
- Grant changes are audit events, and denied connects surface as access-request challenges an admin resolves. That is a live record that restriction is enforced, reviewed, and exception-managed.
A.8.9 Configuration management
Technological
What the control requires
Configurations of hardware, software, services, and networks, including security configurations, must be established, documented, implemented, monitored, and reviewed. Systems run from defined, hardened baselines, changes are managed, and drift from the approved configuration is detected and corrected rather than accumulating silently.
What changes with agents
Agent sprawl means configuration sprawl: every editor, workspace, and MCP client carries its own tool wiring on someone's laptop. There is no baseline to drift from if there is no central configuration at all, and the platform agents run through needs hardening as much as the agents themselves.
What the implementation looks like
An implemented control gives agents one configuration to drift from. Tool wiring lives in a central, versioned configuration that agents receive from the platform rather than hand-edited local files, every change lands in an append-only history, and drift detection surfaces what is running outside the approved estate. Administrative authority over the configuration is itself configured and audited.
How Speakeasy implements the control
Set up
- Make the Deployment the documented baseline. Deployments are append-only, sequenced snapshots, and the active configuration is the latest completed one: what tools exist, from which sources, with which settings, at every point in time.
- Configure administrative authority itself, using RBAC with custom roles for who may change what, plus org-level safety toggles for hooks fail-open and webhooks on or off, which emit audit events whenever their state actually changes.
At runtime
- Coding agents receive their MCP access through the plane rather than hand-edited dotfiles, so the tool baseline lives in one place. Shadow MCP discovery is the drift detector, surfacing servers in use that are not part of the approved estate.
Evidence
- The deployment sequence plus the audit trail is the change history. To restore a prior baseline, redeploy it; the clone records
cloned_fromlineage.
A.8.10 Information deletion
Technological
What the control requires
Information stored in systems, devices, and other storage media must be deleted when no longer required, with defined retention, deletion that actually removes the data including from the places it was copied to, and evidence that disposal happened. Holding data you no longer need is unmanaged risk.
What changes with agents
A retired agent can leave a live refresh token, a forgotten toolset grant, and a memory store full of context, which is an orphaned privileged account plus a data cache, and no leaver process covers either. Decommissioning an agent must enumerate and destroy identity, access, and state.
What the implementation looks like
An implemented control makes deletion enumerable. Retention is enforced by the datastore itself, with hard TTLs per data class, and decommissioning an agent walks a known list: revoke its sessions, keys, and consents, remove its grants, and destroy its state. Each deletion leaves its own record, which is the disposal evidence the clause asks for.
How Speakeasy implements the control
Set up
- Rely on retention enforced by the datastore, not by policy documents. Telemetry tables carry hard TTLs: raw tool-call and hook logs at 90 days, ingestion staging at 2 days, trace and chat-session summaries at 90 days, risk findings at 90 days, spend-usage summaries at 400 days, and long-term metric and token summaries at 730 days.
At decommission
- Offboarding is enumerable because access is centralized. Revoke the sessions of the agent, which invalidates the stored hashed refresh token, along with OAuth consents, remote sessions, and API keys. Remove grants, delete or unpublish its MCP servers and toolsets, and decommission the hosted Assistant runtime.
- Directory offboarding removes organization membership and roles automatically. Include the credential-revocation step in the leaver runbook, since it does not cascade to every token and key by itself.
Evidence
- Each revocation and deletion is an individual audit event, and the TTL schedule is the documented retention answer for agent telemetry.
A.8.15 Logging
Technological
What the control requires
Logs recording activities, exceptions, faults, and other relevant events must be produced, stored, protected against tampering and unauthorized access, and analysed. Logging must capture who did what and when, in enough detail to reconstruct events, and the logs themselves are sensitive assets to protect.
What changes with agents
The events that matter now are prompts, tool calls, approvals, and access grants. When an approved agent action later contributes to an incident, you need to reconstruct the human decision that gated it, not reassess it with hindsight. Most agent stacks log none of this.
What the implementation looks like
An implemented control logs the events that matter for agents: prompts, tool calls, approvals, and grants, each attributed to an actor. Capture depth is a deliberate, per-organization decision, credentials are redacted before events are stored, and the logs sit behind their own access control with sensitive reads logged in turn. A SIEM export keeps agent events in the review process the security team already runs.
How Speakeasy implements the control
Set up
- Decide capture depth deliberately, per organization. Tool-call telemetry always records method, route, URL, status, duration, and byte counts. Request and response content capture is a separate opt-in (
tool_io_logs), capped at 64 KiB per side with an explicit truncation marker. Coding-agent transcript persistence is its own org-controlled switch (session_capture).
At runtime
- More than 170 audit event types record actor and subject identity on every event, with before-and-after snapshots on state-changing updates to keys, grants, policies, deployments, approvals, and org settings.
- Human decisions are events too: bypass approvals, denials, and revocations, warn acknowledgements bound to call fingerprints, and a non-owner opening the session transcript of another user in the dashboard (
chat_session:access). - Credentials stay out of the logs by construction. Gateway-injected security headers are marked for redacted recording with an allowlist for the rest, and device hooks redact MCP transport credentials, meaning URL userinfo and fragments, secret-named query parameters, and tokens in launch commands, on-device before events leave the machine.
Evidence
- Query the audit log by project, time, actor, action, and subject, with actor and action facets, and stream typed audit events outbound via webhooks for ingestion into a SIEM. Logs live behind the access control of the plane: reading them is a permission, and sensitive reads are themselves logged.
A.8.16 Monitoring activities
Technological
What the control requires
Networks, systems, and applications must be monitored for anomalous behaviour, and appropriate action taken to evaluate potential incidents. Monitoring should establish a baseline of normal, detect deviations in real time where feasible, and connect detection to a defined response, not merely accumulate data no one reviews.
What changes with agents
Agents are the new application to monitor, and their anomalies live in prompts and tool calls, not packets. Endpoint and network tools do not parse a prompt injection or a tool call exfiltrating a customer table. Per-agent kill switches do not scale, can be reasoned around by the agent itself, and leave no coordinated containment point.
What the implementation looks like
An implemented control monitors on two planes. Synchronous checks evaluate calls before execution and can block or challenge them, while asynchronous analysis sweeps captured content for patterns that only emerge in aggregate, and both produce severity-scored findings routed to a defined response. Spend guardrails cap runaway execution, and the review itself runs on a documented cadence.
How Speakeasy implements the control
Set up
- Understand the two monitoring planes and use both. Synchronous enforcement runs at the coding-agent hook boundary, where secret detection, PII detection, prompt-injection detection, and custom rules evaluate supported events before the harness executes, with policy actions
flag,warn, orblock. Asynchronous Watchdog analysis batch-scans captured content with the full detector suite, including destructive-command patterns, destructive-tool annotations, Shadow MCP, and account identity. Those last sources are flag-only by design. - Set spend guardrails, with per-person budgets over UTC daily, weekly starting Monday, or monthly windows, evaluated every 30 seconds. Action
blockdenies further Claude Code, Codex, and Cursor agent events whilespend_usd >= limit_usdholds.
At runtime
- A
blockstops the call before execution on supported hook events, and awarnchallenges the user. Findings are recorded masked with severity scores. Containment is coordinated in the plane: policy administration and bypass rights are separately scoped, and every enforcement action is itself audited.
Evidence and integration
- Route typed audit events to a SIEM via webhooks, forward hook logs and metrics to your own OpenTelemetry collector endpoint with best-effort delivery so ingest never blocks agent traffic, and review the Watchdog overview, Agent Sessions, and Tool Logs on a documented cadence. The audit trail proves the review happened.
Synchronous block and warn apply where a pre-execution hook can enforce them: Claude Code, Cursor, Codex, and the unified path. Batch findings do not stop calls that already ran. The spend gate fails open if the cache is down, so agents stay available rather than stalling.
A.8.20 Networks security
Technological
What the control requires
Networks and network devices must be secured, managed, and controlled to protect the information in systems and applications: controlling what can connect to what, segregating traffic, restricting flows to what is authorized, and monitoring the network for abuse.
What changes with agents
The network of an agent is its tool calls. Prompt-injected agents exfiltrate through channels they legitimately hold, using encoded data in URLs, DNS lookups, or many small normal-looking requests, and network controls that never see the tool-call layer cannot distinguish exfiltration from work.
What the implementation looks like
An implemented control treats tool calls as the network. Agent traffic routes through a chokepoint whose allowlist is the deployed configuration, private systems are reached through outbound-only tunnels instead of inbound firewall holes, and standard protections such as SSRF defense apply at dispatch. Payload-level inspection covers what network tools cannot see: exfiltration riding legitimate calls.
How Speakeasy implements the control
Set up
- Route agent tool access through Speakeasy-hosted MCP endpoints. For those endpoints, the reachable tool targets are exactly the Sources in the active deployment, which makes a controlled tool-call chokepoint whose allowlist is the deployment itself.
- Reach private internal systems through the Secure Tunnel. The customer-side agent opens a single outbound WebSocket pinned to one local MCP URL, so there are no inbound firewall holes. The tunnel key is stored hashed and the tunnel route is server-controlled, so a caller cannot supply the tunnel ID.
At runtime
- Outbound HTTP from the control plane enforces SSRF protection at dial time, after DNS resolution. Private and reserved address ranges are blocked by default, redirects are re-checked, and a hostname is rejected if any resolved IP is blocked, so DNS rebinding does not bypass it.
- The payload layer is watched where network tools cannot see. Risk policies inspect hook events synchronously, and Watchdog analyzes captured content for sensitive data leaving through legitimate channels.
Evidence
- The active deployment is the record of which tool targets are reachable, tunnel configuration documents the path to private systems, and Watchdog findings evidence the egress review.
This covers traffic through Speakeasy-hosted endpoints. Coding agents still have native tools and their own network access. Shadow MCP discovery and hook-boundary policies exist to observe and control that remaining path. The control plane is a chokepoint for the toolsets an organization deploys, not for every outbound connection an agent can make.
A.8.31 Separation of development, test and production environments
Technological
What the control requires
Development, testing, and production environments must be separated and secured, with different environments, different access rights, and controlled promotion between them, so untested changes and experimental activity cannot affect production systems or data.
What changes with agents
Agents write and run code as a matter of course. Without enforced isolation, one injected instruction turns a helpful tool into arbitrary execution with production reach, which is the exact collapse of environment separation this control exists to prevent, happening inside a single conversation.
What the implementation looks like
An implemented control gives every agent its own walls. Long-running agents run in isolated, managed sandboxes, agent-written code executes in fresh, resource-bounded processes, and dev, test, and production each carry their own credential set, with promotion between them a controlled, recorded change.
How Speakeasy implements the control
Set up
- Host agents as Assistants. Each runs in its own managed, isolated sandbox runtime, with its configured toolsets and remote or tunneled MCP systems delivered through Speakeasy-hosted endpoints, provisioned and torn down by the plane rather than hand-built on a laptop.
- Run custom tool code as hosted functions on Node.js 22 and 24 or Python 3.12. Each invocation gets a fresh child process with a scrubbed environment and no inherited process env, a 5-minute execution timeout, and bounded memory, defaulting to 1 GiB with a 4 GiB maximum.
- Separate credentials by environment, with distinct Environments per toolset for dev, test, and production. Pointing an agent at production becomes an explicit, auditable configuration change, never an inherited default.
At runtime
- Coding agents inherit the same boundary for their tool access through the plane. Toolset and Environment scoping applies at the endpoint, so editor experimentation does not silently carry production credentials.
Evidence
- Environment attachments and changes are configuration events in the audit trail, and the deployment sequence shows which tools ran against which environment, when.
What the implementation adds up to
Read together, the fourteen controls describe one architecture rather than fourteen separate projects:
- Every agent reaches its tools through a governed enforcement point: hosted MCP endpoints for the agents the organization runs, and the pre-execution hook boundary for the coding agents on employee machines.
- The asset register maintains itself. Agents, tools, MCP servers, and their owners are recorded as a side effect of use, and unsanctioned servers surface from live traffic instead of waiting to be declared.
- Every agent acts as an identity the organization issued and can revoke, with scoped credentials held in encrypted stores and separated by environment, so pointing an agent at production is a deliberate, recorded change.
- Policy runs per tool call. Categories that must never cross the boundary are blocked before execution, judgment calls pause for human acknowledgement, and exceptions flow through an approval queue.
- Everything leaves a record: prompts, tool calls, denials, approvals, and configuration changes, attributed to a named actor, redacted of credentials, and exportable to a SIEM.
Build that once and the fourteen answers above stop being fourteen projects; they become views into the same system, and the evidence an assessor asks for becomes a screen you can open. The executive in the opening quote has a year before agent findings become reportable nonconformities. Most certified organizations hold the same window. For where audit evidence sits across the chat products and their compliance APIs, see the agent compliance reference. To see the controls running in the Speakeasy AI Control Plane, talk to us.