Scaling AI Agents to 10,000 Concurrent Sessions: 7 Governance Controls That Keep the Audit Trail Intact

Key points:

• The compliance blind spot at agent scale is the infrastructure each session touches, and the model has little to do with it. Give every session its own identity, its own scoped short-lived credentials and its own action log, or you will not be able to answer "what did session #8,412 do at 03:12, and who authorised it?" six months later in an audit.
• Seven controls, in order of impact: (1) per-session identity, (2) scoped credentials with a TTL in minutes, (3) runtime isolation, (4) immutable action logging, (5) data residency and egress boundaries, (6) per-session cost and rate caps, (7) a rehearsed kill switch. Infrastructure has to enforce each one. A policy document enforces nothing.
• Human-in-the-loop approval stops working somewhere in the low hundreds of sessions per day. Replace it with policy-as-code (OPA/Rego, Kyverno) plus a hard outer IAM boundary, and keep human approval for an explicit allowlist of irreversible actions: deletes, spend above a threshold and data egress.
• An agent audit log records the action rather than the conversation: session ID, principal, timestamp, tool invoked, parameters, target resource, policy decision, outcome, model and version, stored write-once. EU AI Act Article 12 requires automatic logging for high-risk systems, and Article 19 sets a retention floor of at least six months.
• Running agents inside your own cloud account (AWS, GCP, Azure, Scaleway or an existing Kubernetes cluster) inherits IAM, CloudTrail or Cloud Audit Logs, KMS, VPC egress control and your existing SIEM, an audit perimeter that has already passed SOC 2 and ISO 27001. Vendor-hosted agent runtimes put that evidence in someone else's tenancy.

The compliance blind spot in your agent platform has very little to do with the model. It lives in the thirty thousand short-lived sessions a day that nobody can attribute to anyone. Every one of those sessions holds credentials, calls tools, touches data and then disappears. At 100 sessions you can eyeball that. At 10,000 concurrent sessions you need the infrastructure to do the attributing for you, and most agent stacks I look at were never built to do it.

This article is for the platform or security engineer who is three months from an audit and has just learned the agent pilot went to production. I will go through the seven controls that hold up at that scale, the isolation tiers, the audit log schema, how to replace approval queues with policy, and a 30-day rollout.

Why does AI agent governance break between 100 and 10,000 concurrent sessions?

Agent governance breaks at scale because every control that depends on a human reading something has a ceiling of a few hundred sessions a day. That covers approval queues, log reviews and the activity feed of a shared service account. Above the ceiling nothing goes down. You lose attribution silently: you still have logs, but you can no longer tie an action to a session, a principal or a prompt.

Three things work fine at 100 sessions and fall apart at 10,000:

• A shared service account. One IAM role or API key for "the agent" means CloudTrail shows thousands of identical principals. You cannot separate session #8,412 from session #8,413.
• A Slack approval channel. At a few approvals an hour, people read them. At a few hundred, people click approve.
• Manual log sampling. Reading 50 transcripts a week covers a pilot. It covers a rounding error of a production fleet.

These map onto four blind spots, and the rest of this article closes them one by one:

1. Attribution gap: shared credentials make every action look like it came from the same actor.
2. Credential blast radius: one role with access to every resource means one compromised session can reach everything.
3. Data egress: nobody knows which external endpoints a given session called or what it sent.
4. Non-determinism: the same prompt produces a different action path on different runs, so you cannot reason about behaviour from the code alone.

Non-determinism is the one that breaks traditional change management. Your SOC 2 evidence probably says "this code was reviewed and approved before deploy". With agents, the code is reviewed and the behaviour still varies per run. The evidence has to move from code review to action logs, because the action log is the only record of what the system actually did.

OWASP already names the risk. Its Top 10 for LLM Applications lists Excessive Agency (LLM06), defined as the flaw that "enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs", with three root causes: excessive functionality, excessive permissions and excessive autonomy (OWASP GenAI Security Project). For the multi-agent case, OWASP published its Agentic AI Threats and Mitigations guide in February 2025 as "a threat-model-based reference of emerging agentic threats" (OWASP).

This is a 2026 problem. AWS, Microsoft and Google all ship managed agent runtimes with per-session isolation today (AWS Bedrock AgentCore, Microsoft Foundry Agent Service, Vertex AI Agent Engine). Hyperscalers rarely build that kind of plumbing for pilots.

What are the 7 governance controls that scale to tens of thousands of agent sessions?

Seven controls cover the full surface at scale: per-session identity, scoped short-lived credentials, runtime isolation, immutable action logging, data residency and egress boundaries, cost and rate caps, and a tested kill switch. The test for each one is simple. If enforcing it requires a human to do something per session, it will not survive 10,000 sessions.

1. Per-session identity. Every AI agent session resolves to a unique, traceable principal issued through workload identity federation (IRSA or EKS Pod Identity on AWS, Workload Identity Federation for GKE on GCP, Microsoft Entra Workload ID on AKS), with the session ID stamped into the credential itself, for example as the AWS STS RoleSessionName or SourceIdentity, which CloudTrail records (AWS STS AssumeRole). Never a shared static key. The auditor question it answers: "show me every action taken by this one session".
2. Scoped, short-lived credentials. Every AI agent session receives least-privilege credentials scoped to the exact resources that session needs, with a TTL measured in minutes. AWS STS allows session durations from 900 seconds (15 minutes) and lets you pass a session policy that can only narrow the role's permissions (AWS STS AssumeRole). The auditor question: "what could this session have done, beyond what it did?"
3. Runtime isolation. No AI agent session can read another session's memory, filesystem or network traffic, enforced at the tier that matches the risk (shared process, per-session container, sandboxed runtime or per-tenant namespace). The auditor question: "can tenant A's agent reach tenant B's data?"
4. Immutable action logging. Every AI agent tool call is logged with session ID, principal, parameters, target resource, policy decision and outcome, written to WORM storage such as S3 Object Lock in compliance mode, with separation of duties so the team running the agents cannot edit or delete the log. The auditor question: "reconstruct this session end to end".
5. Data residency and egress boundaries. Every AI agent session records the region it executed in and the external endpoints it reached, and network egress is denied by default with an explicit allowlist per agent class. The auditor question: "did EU customer data leave the EU?"
6. Per-session and per-tenant cost and rate caps. Every AI agent session has a hard ceiling on tokens, tool calls per minute and cloud spend, because a runaway loop is a cost incident and a security signal at the same time. OWASP lists rate limiting as a damage-limitation control for Excessive Agency (OWASP). The auditor question: "what stops an agent from spending or calling without limit?"
7. A tested kill switch. A platform team can revoke credentials and terminate every AI agent session of a given class in under one minute, rehearsed on a fixed schedule with a written drill record. The auditor question: "show me the last time you proved you could stop it."

If you already run the NIST AI Risk Management Framework (NIST AI 100-1) and its Generative AI Profile (NIST AI 600-1), the seven slot into its four functions: identity and credentials (1, 2) belong to Govern, isolation and residency (3, 5) to Map, logging and caps (4, 6) to Measure, and the kill switch (7) to Manage.

How do you isolate tens of thousands of concurrent agent sessions without one cluster per customer?

Isolation is a spectrum, and one question sets the right tier: does the session execute generated code? Read-only, API-calling sessions can share a namespace as long as each has its own identity. Code-executing sessions need a sandboxed runtime like gVisor, Kata Containers or a Firecracker microVM. Regulated multi-tenant workloads need a namespace per tenant with NetworkPolicy, ResourceQuota and separate credentials.

The four tiers:

• Tier 1, shared process. Many sessions in one long-running worker. Cheapest, sub-millisecond session start, zero isolation between sessions. Acceptable only for read-only tools where each session still gets its own credentials.
• Tier 2, per-session container. One pod per session, or a warm pool of pods handed out one per session. Starts in hundreds of milliseconds from a warm image and shares the node kernel. A good default for most tool-calling agents. AWS says it plainly: "Containers are not a security boundary" (Amazon EKS docs).
• Tier 3, sandboxed runtime. gVisor, Kata Containers or Firecracker microVMs, required as soon as agents run untrusted generated code. Firecracker's published specification targets <= 125 ms from the InstanceStart API call to guest /sbin/init and <= 5 MiB of VMM memory overhead for a 1 vCPU, 128 MiB microVM (Firecracker specification). gVisor documents no extra cost for CPU-bound work but notable overhead for syscall-heavy and network-heavy workloads (gVisor performance guide). AWS Bedrock AgentCore uses this model: each session gets "its own dedicated microVM", and memory is sanitized when the session ends (AWS docs).
• Tier 4, per-tenant namespace or cluster. The strongest boundary and the highest cost. The answer when a contract or a regulator demands it.

The Kubernetes primitives that do the work already exist, and the official multi-tenancy guide names them: Namespaces, RBAC, ResourceQuota and LimitRange, NetworkPolicy, sandboxed container runtimes, node isolation, plus Pod Security Admission and workload identity federation for cloud access. The guide also notes that "a common practice is to isolate every workload in its own namespace, even if multiple workloads are operated by the same tenant".

One limit to plan around: EKS Pod Identity supports up to 5,000 associations per cluster (Amazon EKS docs). You will not create one Kubernetes service account per session at 10,000 sessions. Bind workload identity per agent class or per tenant, then mint per-session credentials from it with a session name and a session policy. AgentCore does the same thing natively with the aws:AgentCoreRuntimeSourceSid IAM context key on every session's credentials.

Reuse the pattern you already have. Ephemeral environments per pull request or per tenant are the same lifecycle problem platform teams solved years ago: create on demand, scope credentials, tear down, log everything. You do not need an agent-specific stack for it.

The shortcut to refuse is one long-lived pod serving thousands of sessions under a single IAM role. It is cheap and fast, and it destroys attribution and blast-radius control in one move.

What exactly should an AI agent audit log contain for SOC 2, ISO 27001, and the EU AI Act?

An audit-grade agent log records the action rather than the conversation: session ID, principal, UTC timestamp, tool invoked, parameters, target resource, policy decision, outcome, model name and version, and region. Store it write-once, keep it for at least the period your framework requires, and keep it outside the control of the team operating the agents.

Teams usually conflate three log types, so keep them separate:

• Prompt and completion logs are privacy-sensitive and often full of PII. Useful for debugging and evaluation, and a liability to keep forever.
• Tool-call or action logs are the audit record. This is the table above.
• Infrastructure logs record who deployed the agent, which image, which IAM role and which config. Your CloudTrail, Cloud Audit Logs or Azure Monitor already captures most of this.

Retention. SOC 2 and ISO 27001 do not prescribe a number; your own policy does, and the auditor tests you against it. The EU AI Act does set a floor for high-risk systems. Article 12(1) states that high-risk AI systems "shall technically allow for the automatic recording of events (logs) over the lifetime of the system" (Article 12). Article 19 requires providers to keep those logs, to the extent they control them, for a period "of at least six months, unless provided otherwise in the applicable Union or national law" (Article 19).

Timeline, as of today. The AI Act entered into force on 1 August 2024 (Regulation (EU) 2024/1689). Prohibitions applied from 2 February 2025, general-purpose AI model obligations from 2 August 2025, and most of the Act from 2 August 2026 (Article 113). The AI Omnibus, in force since 27 July 2026, moved the high-risk obligations, including Articles 12 and 19, to 2 December 2027 for Annex III systems and 2 August 2028 for high-risk AI embedded in Annex I products (European Commission). Many older articles still quote 2 August 2026 for high-risk logging. That date is out of date. Whether your agent counts as high-risk depends on its use case, so check that with counsel, but build the log now. Retrofitting a session ID into an orchestrator two weeks before an audit is miserable.

Immutability. Use S3 Object Lock in compliance mode, where a locked object "can't be overwritten or deleted by any user, including the root user". On GCP, use Cloud Storage Bucket Lock, and on Azure, immutable blob storage with time-based retention or legal hold. Write through an append-only sink, and put the bucket in a separate account or project that the agent team cannot administer.

PII. Redact at ingest, before the log is written. Redacting at query time means the raw data already sits in a WORM bucket you cannot delete from. Also watch where logs go: a log that is replicated to another region is a residency violation even when the workload never left.

The dependency nobody budgets for. If your agent platform is vendor-hosted, your audit evidence lives in their account, under their retention policy, in their export format. Ask what happens to it the day you churn.

How do you replace human-in-the-loop approval with policy-as-code at 10,000 sessions?

Human approval survives at scale only as an explicit allowlist of irreversible actions: deletes, spend over a threshold and data egress. Policy-as-code decides everything else at the moment of the tool call. It auto-allows reversible reads, auto-denies anything outside the scoped permission set, and routes the small remainder to a human with the full action context attached.

Classify actions by reversibility and blast radius. The approval requirement follows the action class, never the agent.

The engines already exist. Use OPA with Rego for application-level tool-call decisions in the orchestrator, Kyverno or Gatekeeper for Kubernetes admission, and cloud organisation guardrails as the outer boundary: AWS Service Control Policies, GCP Organization Policy and Azure Policy.

The outer IAM boundary is the one control a prompt injection cannot talk its way past. If the role cannot delete the production database, no clever prompt makes the deletion possible. OWASP's guidance for Excessive Agency says the same: "Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed" (OWASP), and its Prompt Injection (LLM01) entry recommends least privilege and human approval for high-risk operations.

Approval fatigue is worse than no approval. A rubber-stamped queue produces a false audit record: thousands of "approved by human" entries that an auditor will eventually sample, time, and disbelieve when every approval took four seconds.

For agents that touch infrastructure, make plan-then-apply the default. This is the Terraform plan model: the agent produces a diff, the diff is the approval artefact, and the diff is logged next to the action.

The design target I use: the overwhelming majority of actions decided automatically by policy, and a single-digit percentage queued for humans. That is a target to design toward. Nobody has published a measured industry benchmark for it.

Should AI agents run in a vendor's cloud or in your own cloud account?

Run agents in a vendor's cloud for prototypes and low-risk internal tools, and in your own cloud account once you handle customer data or face an audit. The reason is unglamorous. In your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster, five of the seven controls already exist, and they have already passed your SOC 2 and ISO 27001 reviews.

What you inherit in your own account: cloud IAM and workload identity, CloudTrail, Cloud Audit Logs or Azure Monitor, KMS-encrypted log sinks, VPC and PrivateLink egress control, your existing SIEM pipeline, your existing IAM review cadence, and the DPAs and sub-processor lists your customers have already signed.

The vendor options deserve a fair hearing. LangGraph Platform and LangSmith are genuinely strong at agent orchestration and trace-level observability. OpenAI AgentKit and the Agents SDK give you the fastest path from prototype to product. E2B and Modal give you excellent per-session sandboxes. AWS Bedrock AgentCore and Microsoft Foundry Agent Service are a real middle ground: they are managed runtimes, and they run inside your own cloud tenancy. AgentCore gives each session a dedicated microVM. Foundry's standard setup stores agent state in your own Cosmos DB, Storage and AI Search resources so that "all agent data stays in your Azure tenant" (Microsoft Learn). General-purpose PaaS like Render, Heroku or Northflank's managed cloud can host an agent API, but you inherit their tenancy and log retention rather than yours. The honest contrast covers where the audit evidence lives and who holds IAM root. Product quality is a separate question.

Here is where Qovery fits. Qovery is an internal developer platform that deploys and operates applications inside your own cloud account (AWS, GCP, Azure, Scaleway) or on your existing Kubernetes cluster. The cloud bill, the logs and the data stay in your name, and your team gets Kubernetes without managing it directly or hiring a dedicated DevOps engineer to run it.

Mapped honestly to the controls:

• Per-environment RBAC limits who can deploy, configure or reach each agent environment (controls 1 and 3).
• Ephemeral and preview environments per pull request or per tenant give you the namespace-per-tenant lifecycle without hand-written scripts (control 3).
• Environment auto-stop for non-production shuts down idle agent environments, which caps a class of runaway spend (control 6).
• Git-push deployments make the agent runtime itself versioned and reviewable, which is the infrastructure log your auditor will ask for.
• Managed cluster upgrades and databases backed by managed cloud services keep the underlying platform patched without a separate ops project.

The limit, stated plainly: Qovery provides the infrastructure boundary, identity, isolation and environment lifecycle. It does not evaluate individual agent tool calls. That job belongs to OPA, Kyverno and your orchestrator.

The practical migration note: you rarely move the model. You move the execution runtime and the logs, and that is a platform problem rather than an ML one.

What does a 30-day rollout of these controls look like?

Four weeks gets you the four highest-impact controls. Week one removes the shared service account and issues per-session identities. Week two scopes credentials and sets the outer IAM boundary. Week three fixes the action-log schema and makes it immutable. Week four rehearses the kill switch and adds cost and rate caps. Everything after that is refinement.

Each item below is a verifiable outcome:

• Week 1, identity. 100% of agent sessions in the last 24 hours of logs resolve to a unique principal. The shared static key is revoked and its revocation is in the audit log.
• Week 2, credentials and boundary. Median credential TTL is 15 minutes or less. An SCP, Organization Policy or Azure Policy denies destructive actions on production data stores for every agent role, and a test call proves it.
• Week 3, logging. 100% of tool calls in a sampled day carry every field in the audit table. The log bucket is in compliance-mode WORM in a separate account, and the agent team has no delete permission on it.
• Week 4, kill switch and caps. A drill revokes and terminates every session of one agent class in under 60 seconds, with timestamps recorded. Every tenant has a hard spend cap and a tool-call rate limit, and a synthetic loop trips both.

The one-hour version for teams who cannot spare four weeks: revoke the shared static key, set a hard spend cap, and turn on tool-call logging with a session ID field. That alone moves you from "we can't tell" to "we can tell, roughly".

Four metrics to track afterwards: percentage of sessions with a unique principal, median credential TTL, percentage of actions with a complete log record, and time-to-revoke-all from the last drill.

What you hand the auditor at the end: the written policy, three sampled end-to-end session reconstructions, the kill-switch drill record with timestamps, and the access review showing who can edit or delete logs (ideally nobody on the agent team).

The rollout usually stalls in one of three places. The orchestrator does not emit a session ID, so nothing downstream can join on it. Logs land in a mutable bucket "temporarily" and stay there. Or nobody owns the kill switch, so the week-four drill never gets scheduled. Assign an owner for each on day one.

How do I set this up from Claude Code or Cursor?

The same governance logic applies to the coding agent on your laptop. Install the Qovery Agent Skills once, and your agent gets scoped deployment actions into your own cloud account instead of raw cloud credentials. The Qovery MCP Server is read-only by default, and that default is deliberate.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scope the skills to the current repository only
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the Qovery MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you want it (also requires enabling write access in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Treat the read_write=true toggle as your approval boundary and leave it off by default. In read-only mode the agent can inspect environments, services and deployments but cannot change them (Qovery MCP Server docs).

The skill set includes qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform. The skills deploy; the MCP Server operates what already exists. After installing, ask in plain language, for example "deploy this service to my GCP account with Qovery". The full walkthrough is in the AI agent quickstart and on the Claude Code integration page.