One Public AI Coworker Should Not Open the Door to Your Whole Team

One Compromised AI Coworker Should Not Become the Whole Team

On October 8, security researchers at Zenity published an account of their AgentCorruption research: in a test environment, they said credentials obtained from one public-facing AI role let them reach other roles and their data in the same AWS account and region. The operational question is bigger than one cloud product. If someone gains control of your least-trusted AI coworker, what else does that coworker's identity let them touch?

There is an important qualification. Zenity described a chain involving access to a workload's temporary credentials and permissions it observed on a default execution role. AWS disputed the characterization of expected behavior as a vulnerability, and The Decoder reported both sides of the dispute. AWS and the researchers also describe changes to metadata access and default permissions since the original disclosure. This is not a claim that every current AgentCore deployment is exposed, or that sharing a cloud region alone makes roles mutually accessible.

The lesson survives that disagreement: runtime isolation and role isolation are different properties. A runtime may keep workloads in separate machines while the credentials available inside one workload still grant authority over others. AWS's own runtime security guidance says code inside a microVM can access its execution-role credentials, warns against using broad CLI-generated policies in production, and recommends permissions scoped to the resources a role actually needs.

For a small business, this is a team-design problem, not a reason to abandon AI coworkers. A support Teammate that reads public questions and drafts replies should not have a route into a finance Teammate's records, a sales Teammate's contact exports, or the system that controls deployments. Distinct job descriptions do not create distinct security boundaries. The access rules do.

AI Coworker Isolation Is More Than a Separate Workspace

It is easy to mistake visual separation for enforced separation. Give each AI coworker a name, a chat channel, a workspace, and a different set of instructions; the org chart looks orderly. Yet if all roles run with a shared credential that can list every file store or call every connected system, an error or a hostile request entering through one role can cross the chart.

Three boundaries matter. The execution boundary limits where code runs and what it can reach on the network. The identity boundary limits what the workload's credentials can access. The decision boundary limits which actions the business authorizes, even if a technical credential would permit them. A firewall cannot decide whether a refund is legitimate. A prompt saying “do not access payroll” cannot revoke a credential that can read payroll. Human approval cannot retrieve information already disclosed to an untrusted role.

The AgentCorruption account makes the second boundary concrete. Zenity said the permissions it examined were broad across resources in an account and region, allowing movement from an exposed role into other runtime and memory resources. AWS's current permissions documentation explicitly says development-oriented generated policies are broad and not suitable for production, and advises custom policies limited to necessary actions and resources. The fix for a business is not merely to add stricter words to each role's instructions. It is to limit authority outside those instructions and verify the limitation from the role's actual runtime identity.

This extends to memory. A durable AI coworker needs to remember the work it owns, but “durable” does not mean every teammate can read every conversation. A support role may need the current customer's ticket history. It does not need access to the finance team's cash-flow discussions or the private notes behind an employment decision. If one shared memory store is unavoidable, the business still needs per-role and per-customer access controls and a way to verify them. A folder naming convention is not a permission system.

There is also a difference between a user asking one Teammate to hand work to another and one runtime being able to invoke every other runtime at will. A legitimate handoff should have a narrow path, a defined purpose, an identifiable requester, and an audit record. Broad cross-role invocation turns a public entry point into an internal dispatcher without a business decision about who is allowed to dispatch what.

What bad and good isolation look like

Bad: A small retailer connects one shared integration account to its customer-support, purchasing, and bookkeeping AI coworkers. The support role receives untrusted customer messages. Its integration account can read supplier invoices and create accounting entries because granting full access was easier during setup. Different names and instructions hide a single permission set. If a support session is redirected or its credentials are misused, the finance boundary is already gone.

Good: The support role can read only the ticket and order status needed to answer the customer; refunds require a separately authorized human workflow. Purchasing can prepare reorder recommendations against a scoped inventory view but cannot change ledger entries. Bookkeeping receives its own read permissions and sends exceptions to an accountable reviewer. Inter-role handoffs transmit the minimum required facts through an approved route rather than passing around a master credential. A test using the support role's actual identity fails when it attempts to retrieve finance data.

Neither design assumes that the AI coworker is malicious. The good design lets the business keep running when a model makes a mistake, a connected page contains hostile instructions, or a credential is stolen. That is trust architecture: safety is a property of what the system permits, not a hope that every request will be interpreted correctly.

Map the Blast Radius Before You Add Another Role

A business does not need a large security team to ask the right questions. It does need a written map of the paths its AI coworkers can take. Start with the lowest-trust role: the one reading public emails, web forms, support messages, or outside documents. For each role, record four things: the data it can read, the actions it can perform, the credentials it runs with, and the other roles or services it can reach.

Do not map only the UI's advertised connectors. Check the identity underneath the runtime. A person may see “read support tickets” in a configuration screen while the integration credential belongs to an administrator with much broader rights. In a cloud deployment, look at the execution role and the resource policies that authorize its requests. For a hosted platform, ask the provider for the enforced separation between Teammates, credentials, workspaces, and customer data—not just a diagram of separate chat threads.

Draw arrows from each role to every reachable resource. Mark an arrow read, write, invoke, administer, or approve. “Can ask another role to do work” and “can edit that role's configuration” are very different arrows. The map should show both. Then classify the consequences of each path: public information, internal operations, sensitive customer data, payment authority, security configuration, or irreversible external effect.

The most valuable question is not “Is this role secure?” It is “What is the maximum damage if this role behaves incorrectly for one hour?” That question turns a vague safety conversation into decisions about boundaries. If a public support role can read a bank file, the design is wrong even if the support role has never tried. If a marketing Teammate can draft a site change but cannot publish without review, that limitation remains useful whether the model is excellent or confused.

This is different from the identity-versus-permission question, which asks whether a specific action is authorized. Cross-role isolation asks whether an initial compromise can inherit an entirely different job's authority. Both questions belong in the same review, but they test different failure modes.

The test is a denied action, not a green checkmark

A configuration page showing separate roles is evidence of intent. A negative test is evidence of enforcement. In a nonproduction environment, use the public-facing role's actual identity to attempt a harmless read against a finance-only record and a harmless request to an internal-only workflow. Both should be denied by a control outside the model. The test should not depend on the AI coworker saying, “I am not allowed to do that.”

Record the denied request, the rule that stopped it, the person responsible for that rule, and the date. Repeat after changing a connector, adding a skill, rotating credentials, or moving a role to a different agent server. A new integration can quietly widen authority even when nobody edits the original role definition. Do not use live sensitive data or a destructive action as your proof; use a synthetic record and a safe, reversible test path.

If you cannot run a denied-action test, say what is unknown. “The provider says roles are isolated” is not the same evidence as “our support identity was denied access to this finance resource.” AWS's guidance on credentials is unusually explicit: any code or actor inside the workload can access execution-role credentials through the metadata service, so the role itself must carry no more authority than the workload should exercise. The same reasoning applies beyond AWS wherever an AI coworker can use a shared key or service account.

A Seven-Step Cross-Role Isolation Plan for Small Teams

1. Name the roles and the owner of each. List every AI coworker that runs or is in pilot, including the ones built by an individual department. Assign a human owner who can approve access and revoke it. “Nobody owns the old support automation” is an incident waiting for an inbox.

2. Inventory credentials from the runtime outward. For each role, capture which identity the system actually uses to read data, call an API, access memory, and hand work to another role. Include inherited permissions, not just the permissions shown in the role editor. Never copy credential values into the inventory; record the key name, location, scope, and rotation owner.

3. Separate public entry points from sensitive roles. Public-facing work encounters untrusted material by design. Put its data and actions behind tighter, independent scopes than finance, personnel, deployments, or administrator functions. Separate agent servers or accounts may be warranted where the impact demands a harder boundary, but separation only works if shared credentials and wide resource policies do not reconnect them.

4. Replace broad grants with task-specific grants. Give the support role order-status lookup, not unrestricted customer export. Give the bookkeeping role a defined set of read operations for reconciliation, not payment authority. Scope each permission to a resource and action where the connected service supports it. If it does not, put a controlled gateway or human handoff between the role and the risky action.

5. Design handoffs as contracts. Specify who may request a handoff, what data crosses it, which role accepts it, what result returns, and when a person must approve. A support-to-finance escalation can transmit an order ID and the customer's question without handing the support role finance credentials. Log the original requester and the acting role separately.

6. Run the negative tests and keep the evidence. Test denial across the most important role boundaries using synthetic data. Check reading, writing, memory access, and cross-role invocation separately. A failed attempt to read a file does not prove that an API call is blocked. Include the test in your change review whenever a connector or role policy changes.

7. Prepare containment before you need it. Know how to disable the exposed role, revoke its credential, pause its scheduled work, and identify which other roles or data stores that identity could reach. Preserve logs and notify affected owners before restarting. A clean rollback of the role's configuration does not automatically reverse an external action it already performed; treat recovery and authorization as separate jobs. The rollback-design guide explains the recovery side.

This plan is deliberately smaller than an enterprise identity program. It gives an owner of a three-role AI team a concrete proof standard: one role cannot silently acquire another role's data or authority. Expand the tests as the org chart grows. A team remains a team because it can hand work across roles intentionally, not because every role shares the same master key.

FAQ

Q: Does a separate agent server guarantee AI coworker isolation? A: No. It separates some runtime resources, but shared credentials, broadly scoped APIs, common memory stores, or unrestricted cross-server messaging may reconnect the roles. Test the effective access from each role's identity.

Q: Was every Amazon Bedrock AgentCore deployment vulnerable to the reported chain? A: That is not established. Zenity reported behavior in its tested configuration and disclosure timeline; AWS disputes part of the vulnerability characterization, and both sources describe changes since the initial findings. Review your actual roles against current vendor guidance rather than assuming either universal exposure or universal safety.

Q: Can a better system prompt prevent one role from reaching another? A: Instructions help define work, but they do not narrow a credential. Enforce the boundary through role-specific permissions and resource controls; then verify that a denied action stays denied even if the AI coworker asks for it.

Q: Should AI coworkers ever share memory or call one another? A: Yes, when the business has a defined purpose and a constrained route. Share the minimum facts needed for the handoff, authorize the receiving role independently, and retain an audit trail. Shared context should not mean unrestricted access to every private conversation.

Q: What is the first test for a small business? A: Pick the public-facing role and a sensitive record it should never read. In a safe test environment, make a request using the role's real permissions and verify that an external access control—not a polite model refusal—denies it. Record the result and repeat after access changes.

If you're building an org chart of AI coworkers rather than a collection of shared logins, Associates AI Teammates gives you configurable roles on agent servers with distinct Skills and operating boundaries. View pricing and choose a plan when you're ready to put those boundaries into practice.