How Axonius built tenant-safe AI agents with AWS Bedrock AgentCore

How Axonius added tenant-safe AI agents using Bedrock’s AgentCore runtime

Axonius manages asset data from more than 1, 400 systems and wanted agents that can run live queries, fetch data, and draft answers for customers, without changing their strict per-customer security model, identity flows, cost visibility, or operational playbooks. The engineering brief looks like a constraint checklist: keep tenant isolation airtight, preserve existing VPC placements and IAM, and instrument every token so billable usage never surprises finance.

TL;DR: Axonius implemented a dedicated Bedrock AgentCore runtime per customer (a “silo” tenancy model) and kept shared services private via VPC Lattice. The team says this cut their integration work from an estimated eight weeks to ten days, roughly an 82% reduction in calendar time, per Axonius, by reusing AgentCore’s built-in isolation, VPC integration, and observability primitives.

Three multi-tenant patterns, short decision matrix

  • Silo, Dedicated runtime per tenant. Highest isolation and easiest mapping to existing VPC/IAM controls, but higher infra footprint per customer. Best when customers already live in isolated VPCs.
  • Pool, Shared runtime serving many tenants with session-level isolation. Lowest infra cost but puts more responsibility on app-level routing, JWT claims, and audit trails.
  • Bridge, Shared runtime plus a gateway that enforces per-tenant tool access (policy language + interceptors). Middle ground: cost efficient with additional enforcement surface to operate and secure.

One-line tradeoff: isolation ↔ cost density ↔ operational complexity. Pick the point on that triangle that matches your security posture and customer expectations.

Why Axonius chose the silo model

Axonius already runs each customer in isolated VPCs. They needed deterministic, infrastructure-level boundaries rather than trusting application routing or one-off policy hacks. Bedrock’s AgentCore runtime supplied three decisive capabilities, per Axonius and AWS:

  • Per-session microVM isolation (AgentCore allocates a microVM for each session, a lightweight, ephemeral VM providing isolated CPU, memory, and filesystem), which limits blast radius between sessions.
  • ENI-based placement (ENI = Elastic Network Interface) so the runtime appears inside the customer VPC and can reach EC2-hosted Axonius instances and other private resources without exposing credentials over the public internet.
  • Built-in observability hooks for CloudWatch, X-Ray, and tracing instrumentation, matching Axonius’s existing monitoring and cost attribution workflows.

“AgentCore Runtime gave us the multi-tenant isolation and authentication framework we needed to deploy AI agents across large numbers of customer environments without compromising our security-first architecture.”, Dori Shmuel, SaaS DevOps Lead, Axonius

How the architecture fits together, concrete pieces and operational impacts

  • Per-tenant AgentCore runtimes: Each customer receives a runtime deployed into their VPC with an attached ENI (so runtime traffic is local to the VPC). Impact: isolates network-level access and simplifies compliance mapping, but increases per-customer infrastructure footprint.
  • Shared services via a services VPC + Amazon VPC Lattice: Axonius keeps common services in a central VPC and publishes them into customer VPCs using VPC Lattice (one private endpoint per service). Impact: avoids the per-VPC PrivateLink cost and scales service exposure in a predictable way.
  • Bedrock-backed Knowledge Bases for RAG: Agents use Bedrock Knowledge Bases (RAG = retrieval-augmented generation) with an S3-backed vector index for document grounding and scalable, cost-efficient storage. Impact: answers are grounded in documentation and stored content rather than ad hoc model hallucinations.
  • Short-lived impersonation JWTs: The Axonius frontend mints short-lived JWTs carrying user identity, tenant ID, session ID, and actor ID. These tokens are passed to AgentCore at InvokeAgentRuntime. Impact: limits credential exposure and scopes every runtime action to a tenant/session context.
  • Invoke payload and memory handling: InvokeAgentRuntime includes AgentCore Memory ID, KB/data-source IDs, region, product version, and callback address. Sensitive authentication material is kept in headers and intentionally excluded from persisted AgentCore Memory (per Axonius/AWS guidance).
  • Per-tenant container images + provisioning automation: Agent images live in Amazon ECR and per-tenant runtime lifecycle (create/teardown) is handled by CloudFormation/CDK automation. Impact: operational consistency and repeatable onboarding.
  • Observability and tracing: CloudWatch metrics, X-Ray distributed traces, and opentelemetry instrumentation capture latency and token use (opentelemetry provides near-real-time token telemetry). Impact: actionable signals for performance tuning and cost control.

Token governance, cost attribution, and enforcement

Model tokens are the primary cost driver, so Axonius built layered controls:

  • CloudWatch collects aggregate input/output token metrics per agent. Opentelemetry instrumentation provides higher-fidelity token counts for enforcement and alerting.
  • IAM role tagging, using Bedrock’s cost allocation features by IAM user/role, ties model calls back to tenant-scoped roles so spend can be attributed and charged back.
  • Application Inference Profiles and Amazon EventBridge enable tagging, alerts, and downstream automated actions when thresholds are crossed.
  • Automated enforcement: alarms can trigger automated IAM-deny policies or throttles to stop runaway spend.

Note: the design documents report cost visibility for accounting-level allocation “once or twice daily, ” while opentelemetry and CloudWatch provide the higher-frequency signals used for enforcement and alerts.

Guardrails, RAG, and data handling

Axonius uses Bedrock Knowledge Bases to ground answers with product documentation and customer data. Amazon Bedrock Guardrails, which perform server-side filtering and topic-denial checks, run before model outputs leave Bedrock to reduce leakage and inappropriate responses. AgentCore Memory preserves conversation context across follow-ups, while authentication tokens are excluded from persistent memory to reduce the risk of accidental storage.

Those are meaningful mitigations, but implementers still bear responsibility for retention policies, data lifecycle, and compliance mapping. Bedrock features help, they do not replace governance work.

When pool or bridge models make sense

  • Pool model, If you need to minimize infrastructure cost and can invest heavily in application-level identity routing and auditing, a pooled runtime can work. AgentCore still provides session microVM isolation, but you must make JWT claims and tenant routing rock-solid and accept a larger audit burden.
  • Bridge model, Use when you want shared runtimes but need strict tool-level access control. The AgentCore Gateway can enforce Cedar rules (Cedar = declarative access-policy language) and use REQUEST/RESPONSE Lambda interceptors to exchange a JWT for short-lived tenant-scoped IAM credentials via STS AssumeRole, the “act-on-behalf” pattern. Impact: better tooling controls at the cost of an extra enforcement surface and operational complexity.

Operational wins, and what’s still open

Axonius reports a major operational win: what they expected to take eight weeks of infrastructure and plumbing work became production-ready in ten days, about an 82% reduction in calendar time, per Axonius. They credit AgentCore’s built-in isolation, VPC connectivity, and observability for that speed.

That said, important practical details were not provided and should be treated as follow-ups if you’re evaluating the same pattern:

  • No dollar-per-token or per-tenant cost breakdown was provided, so you’ll need to model token volumes and ask your provider for region/model pricing.
  • Scale and performance numbers are absent: the total number of tenant runtimes Axonius runs in production, latency under concurrent sessions, and throughput benchmarks were not shared.
  • Failure modes and incident handling specifics, such as network failures, runtime crashes, model errors, and mean time to recover, are not covered in the public notes.
  • Service quotas: AgentCore is reported to have a default quota of 1, 000 agents per AWS account. If you expect higher concurrency, plan quota requests or multi-account strategies in advance and confirm limits with AWS.

Who collaborated on the implementation

This design and write-up reflect a collaboration between Axonius engineers and AWS specialists: Amir Krispin, Yaakov Tayeb, Yossi Lagstein (AWS), and Axonius DevOps leads Dori Shmuel and Omar Sawara. The architecture and operational choices described above are reported by those teams.

Key takeaways, questions you’d actually ask

  • How does Axonius prevent tenant data and credentials from leaking between customers?

    They deploy a dedicated AgentCore runtime per tenant with an ENI placed inside the customer VPC and rely on per-session microVM isolation. Short-lived impersonation JWTs scope actions to user/tenant/session. Authentication material is kept out of persistent AgentCore Memory. Bedrock Guardrails filter model outputs before they leave the service, per Axonius/AWS.

  • How do they attribute and control model costs?

    Token consumption is captured in CloudWatch and via opentelemetry instrumentation. IAM role tagging ties Bedrock model calls back to tenant roles for cost allocation. EventBridge and Application Inference Profiles enable alerts and automated actions. Alarms can trigger IAM-deny policies or throttles to stop runaway spend.

  • Why not use a shared runtime (pool) to save money?

    Shared runtimes reduce per-tenant infra costs but push identity routing, policy enforcement, and auditability into application logic or gateway code. Axonius chose siloed runtimes because they already run customers in isolated VPCs and preferred deterministic, infra-level isolation that aligns with enterprise compliance expectations.

  • What if I want the middle ground (bridge)?

    The bridge model uses a shared runtime but enforces per-tenant tool access at the gateway with Cedar rules and REQUEST/RESPONSE interceptors. Interceptors can implement STS AssumeRole exchanges, the “act-on-behalf” pattern, to obtain short-lived tenant-scoped credentials for tool calls, limiting reach at invocation time.

  • How fast can you get to production with AgentCore?

    Axonius reports a drop from an estimated eight weeks of custom integration work to ten days of production-ready deployment, about an 82% reduction in calendar time, by using AgentCore’s runtime isolation, VPC integration, and observability features. Your mileage will depend on onboarding automation, quota limits, and how tightly you integrate tenancy provisioning with your customer lifecycle.

For ISVs deciding how to add agentic features: match the tenancy model to your existing security posture and customer SLAs. If you already run siloed VPCs, a per-tenant AgentCore runtime preserves that model and provides network-level isolation plus the observability hooks you need. If cost density is the priority, prototype a pooled or bridged model early, but treat enforcement, such as Cedar policies, STS exchanges, and token telemetry, as the hard engineering problem, not an afterthought.

0