AgentCore resource-based policies add Runtime, Gateway, and Memory access controls for SaaS agents. Review tenant isolation patterns today.
What resource-based policies change for multi-tenant agents
AgentCore resource-based policies give SaaS platforms a way to control who can invoke an agent and which agent resources that caller may touch. Instead of relying only on the caller’s identity policies, the agent Runtime, Gateway, and Memory each carry their own policy surface. That lets a platform deny cross-tenant access even when a shared service role is broad, because the resource itself can refuse the request.
For tenant agents, the practical shift is clear: isolation is no longer only “the orchestrator checks the tenant ID.” Runtime access, gateway routes, and memory stores become first-class enforcement points. Design around that: every agent instance, gateway entry, and memory namespace should be addressable as a resource that can express allow/deny rules scoped to a tenant.
Runtime, Gateway, and Memory as separate control planes
Treat the three surfaces as complementary, not interchangeable. Runtime policies govern who can start, stop, or invoke an agent execution. Gateway policies govern who can reach the agent through the published interface—API keys, IAM principals, or other callers that never touch the runtime API directly. Memory policies govern who can read or write long-lived state the agent depends on between sessions.
A common failure mode is tightening Runtime while leaving Gateway open, or locking both while Memory remains readable across tenants. Cross-tenant leakage often travels through the softest surface. When you review isolation, map each tenant’s data path: request enters via Gateway, execution runs in Runtime, and durable context lives in Memory. Every hop should fail closed for foreign tenants.
- Runtime — limit invoke and lifecycle operations to the owning tenant’s principals or a narrow platform role that injects tenant context.
- Gateway — bind routes, credentials, and routing keys to a single tenant; reject unscoped or mismatched identifiers before the agent runs.
- Memory — partition stores or keys by tenant; deny list/read/write outside that partition even for shared operational roles.
Tenant isolation patterns that hold under load
Prefer resource-per-tenant or hard namespacing over soft filtering in application code. Soft filters (query with a tenant ID and hope every path includes it) break under new endpoints, admin tools, and async workers. Resource-based policies push the boundary outward: the wrong principal cannot call the resource at all, so a missing filter is less catastrophic.
Where full per-tenant resources are costly, use a hybrid: shared infrastructure with tenant-scoped resource ARNs or identifiers, and policies that require a matching tenant condition on every sensitive action. Keep platform “break-glass” roles rare, logged, and time-bound. Document which principals may cross tenant boundaries for support, and which agent resources must never allow that path.
A review checklist for SaaS agent fleets
Walk an existing deployment by picking one tenant and one foreign principal. Attempt Runtime invoke, Gateway call, and Memory read with the foreign identity. All three should deny. Then attempt the same with a legitimate tenant principal that lacks a specific action—least privilege should still hold. Fix any path that succeeds on identity alone without a matching resource policy.
Finally, align lifecycle with policy: when a tenant is offboarded, revoke Runtime and Gateway access and quarantine or delete Memory before decommissioning the agent. Policy updates without memory cleanup leave residual data; memory cleanup without gateway denial leaves a route that can recreate or rehydrate state. Resource-based controls on Runtime, Gateway, and Memory only work as a set—review them together, and keep them in sync as you add agents and tenants.