Axonius Multi-Tenant Agent Architecture: How Bedrock AgentCore Isolates Hundreds of Customer Environments

Multi-tenancy is the hardest unsolved problem in agentic infrastructure. Most frameworks assume single-user or single-org contexts. When you need to run hundreds of isolated agent environments for different customers on shared infrastructure, you either build custom compute sandboxing, tenant-aware logging, and authentication plumbing from scratch, or you find a platform that handles it natively.

Axonius, a cybersecurity SaaS provider, chose the second path. They deployed agents across hundreds of customer environments using AWS Bedrock AgentCore, avoiding the need to build custom isolation, authentication, or observability infrastructure. AWS published a detailed case study showing how the architecture works in production.

The Multi-Tenant Agent Problem

When you deploy agents in a SaaS context, you face three hard problems:

Compute isolation: One tenant’s agent cannot access another tenant’s memory, tool calls, or API credentials. Traditional approaches require separate VPCs, container orchestration, or custom runtime sandboxing.

Authentication boundaries: Each agent needs scoped permissions for tools and data sources. A single misconfigured role or leaked credential can expose multiple tenants.

Observability without leakage: Each customer needs isolated logs, traces, and audit trails. Cross-tenant data leakage in observability pipelines is a common compliance failure.

Most agent frameworks punt on these problems. They assume you will handle multi-tenancy at the application layer, which means building custom plumbing for every isolation boundary.

How AgentCore Handles Isolation

Bedrock AgentCore provides tenant isolation as a first-class primitive. Here is how it works:

Per-tenant agent instances: Each customer gets a dedicated agent instance with its own execution context. Instances do not share memory, state, or tool credentials.

IAM-based tool scoping: Tool permissions are scoped per agent instance using IAM roles. Each agent assumes a role that grants access only to the tools and data sources for that tenant. Role assumption happens at invocation time, not at deployment time.

Execution isolation: Agent invocations run in isolated compute environments. A failure in one tenant’s agent does not affect other tenants. Blast radius is contained to the failing instance.

Audit logging per tenant: CloudWatch Logs and CloudTrail events are tagged with tenant identifiers. Each customer can query their own logs without seeing data from other tenants.

This approach eliminates the need for custom compute sandboxing or tenant-aware logging infrastructure. You configure IAM policies and agent instances, and the platform enforces isolation.

Architecture: How Axonius Deployed It

Axonius runs a cybersecurity SaaS platform that aggregates data from customer IT environments. They needed agents to query internal APIs, analyze security posture, and generate reports. Each customer environment has different API credentials, data sources, and compliance requirements.

Here is the deployment shape:

Agent provisioning: When a new customer onboards, Axonius provisions a dedicated AgentCore instance. The instance is tagged with the customer tenant ID.
Tool registration: Each agent instance registers tools (API clients, database connectors, report generators) with scoped IAM roles. The role grants access only to the customer’s data sources.
Invocation flow: When a customer triggers an agent task, the request includes the tenant ID. AgentCore routes the request to the correct agent instance and assumes the scoped IAM role.
Observability: Logs and traces are written to CloudWatch with tenant ID tags. Axonius queries logs per tenant using tag filters. Cross-tenant queries are blocked at the IAM policy level.
Failure handling: If an agent instance fails, AgentCore retries the task in a new execution context. Other tenants are unaffected. Failed instances are logged with tenant-specific alerts.

Isolation Primitives in Practice

The key to this architecture is IAM-based scoping. Here is a simplified example of how tool permissions work:

# IAM policy for a tenant-scoped agent role
PolicyDocument:
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Action:
        - bedrock:InvokeModel
      Resource: "arn:aws:bedrock:*:*:model/*"
    - Effect: Allow
      Action:
        - dynamodb:GetItem
        - dynamodb:Query
      Resource: "arn:aws:dynamodb:*:*:table/customer-data-${TenantId}"
      Condition:
        StringEquals:
          "dynamodb:LeadingKeys": ["${TenantId}"]
    - Effect: Allow
      Action:
        - logs:PutLogEvents
      Resource: "arn:aws:logs:*:*:log-group:/aws/bedrock/agents/${TenantId}/*"

The ${TenantId} variable is injected at role assumption time. Each agent instance can only access DynamoDB items and logs for its own tenant. The LeadingKeys condition enforces row-level isolation in DynamoDB.

This pattern extends to all tools. API credentials are stored in AWS Secrets Manager with tenant-scoped access policies. S3 buckets use prefix-based isolation. Lambda functions are invoked with tenant-specific environment variables.

Observability and Blast Radius

When an agent fails, you need to know which tenant was affected and why. AgentCore writes structured logs to CloudWatch with the following fields:

tenantId: Customer identifier
agentInstanceId: Unique instance ID
invocationId: Request trace ID
toolName: Which tool was called
errorType: Failure category (auth, timeout, validation)

Axonius queries these logs per tenant using CloudWatch Insights. Each customer sees only their own logs. Cross-tenant queries require elevated IAM permissions, which are restricted to Axonius operators.

Blast radius is contained by instance isolation. If an agent in one tenant environment fails, other tenants continue running. AgentCore does not share execution state across instances. Retry logic is per-instance, so a failing tenant does not exhaust shared retry budgets.

Trade-offs and Failure Modes

Component	Benefit	Risk
IAM-based scoping	No custom auth logic, AWS-native audit trail	Complex policy debugging, role assumption latency
Per-tenant instances	Strong isolation, independent scaling	Higher instance count, provisioning overhead
CloudWatch tagging	Native log isolation, query per tenant	Tag injection errors can leak logs across tenants
Secrets Manager	Encrypted credential storage, rotation support	API rate limits, cross-region replication lag
DynamoDB leading keys	Row-level isolation, no custom query logic	Schema must include tenant ID in partition key

The biggest failure mode is tag injection errors. If a tenant ID is incorrectly tagged, logs or metrics can leak across tenants. Axonius mitigates this with automated tag validation at provisioning time and periodic audits of CloudWatch log groups.

Another risk is IAM policy drift. If a policy is updated without tenant-scoped conditions, an agent could gain access to another tenant’s data. Axonius uses AWS Config rules to detect missing conditions and alert on policy changes.

When to Use This Pattern

This architecture makes sense when:

You are deploying agents for multiple customers on shared infrastructure
Each customer has different data sources, API credentials, or compliance requirements
You need strong isolation guarantees without building custom compute sandboxing
You want AWS-native audit trails and observability

Avoid this pattern when:

You have a single-tenant deployment or a small number of customers (the provisioning overhead is not worth it)
Your agents do not access sensitive data or credentials (simpler namespace-based isolation may suffice)
You need sub-second invocation latency (IAM role assumption adds 50-200ms per request)
You are running agents outside AWS (this pattern is tightly coupled to IAM and CloudWatch)

Technical Verdict

Bedrock AgentCore solves the multi-tenant agent problem by making isolation a platform primitive instead of an application concern. Axonius avoided building custom compute sandboxing, authentication, or observability infrastructure. The trade-off is tight coupling to AWS IAM and CloudWatch, plus the operational overhead of managing hundreds of agent instances.

If you are deploying agents in a SaaS context and already use AWS, this pattern is the fastest path to production-grade isolation. If you need cross-cloud portability or sub-100ms invocation latency, you will need custom plumbing.

The key insight is that multi-tenancy is not a feature you bolt on later. It is a deployment constraint that shapes your entire architecture. AgentCore handles it natively, which is why Axonius chose it over building their own agent runtime.

Source Links

AWS ML Blog: How Axonius built secure multi-tenant AI agents on Bedrock AgentCore

Agentic AI, minus the noise.