Keep User Permissions Intact Across Multi-Source AI Agents

In the same sales assistant, an account executive asks for "this quarter's priority contracts," while a finance manager asks for "payment records for account X." Both interact with the same agent, and both refer to "clients."

If your AI agent holds a master key to all your CRM instances, document repositories, and databases, the biggest risk is not that it hallucinates. The real danger is that it answers with complete fluency—using data that specific user had no right to see.

On August 19, 2026, AWS published architecture guidance for propagating authorization context across multi-source AI agents using Amazon Bedrock AgentCore. The core principle: pass the end user's identity and operational scope—department, role, region, or project—from login all the way to databases, knowledge bases, and external CRMs. Downstream systems make their own decisions to grant or deny access based on their existing rules.

This approach does not rely on adding another layer of prompt defense. It moves access control back to reliable infrastructure and backend systems, where it belongs.

Distinguish "Who Is Executing" from "On Whose Behalf"

Many organizations already give AI agents identities, API keys, and tool permissions. Yet they miss a critical link: when an agent queries data for an employee, downstream systems cannot tell whether the request belongs to the agent itself or to a specific user operating within a specific business scope.

When this context breaks, the agent defaults to a high-privilege service account. Teams then try to patch the gap by adding application-level filters, trusting the model to return only what the user is allowed to see.

This design turns the agent into a security gatekeeper—a role it was never built for. Prompt injections, logic errors during tool execution, or simple query rewrites can cause application-level filters to fail.

The AWS implementation solves this by validating the user's signed identity token in the runtime environment and binding the user's scope to short-lived, request-scoped credentials. The agent interprets queries and orchestrates tools, but it never arbitrates who gets to see what.

Treat an AI agent as an operational coordinator, not an access judge. It can formulate queries, but it should never possess the authority to bypass underlying data security models.

Three Data Sources, Three Required Hand-offs

1. Structured Business Data

For structured records such as orders, customer profiles, inventory, or payments, never let an agent query the entire table and filter results afterward. Use short-term credentials tied directly to the user's scope. This forces the database or IAM policy to reject cross-department or cross-region data before the query executes. Even if an agent is tricked into querying unauthorized partitions, it receives nothing.

2. Enterprise Knowledge Bases

When documents enter a repository, tag them with metadata: department, project, account, or classification level. At retrieval time, convert user scope attributes into hard filter criteria.

Be realistic about repository architecture: some knowledge bases still execute metadata filtering at the application layer. For sensitive information, relying on search filters is not enough. You should physically or logically separate repositories across security domains or tenants, enforcing access through resource policies.

3. External SaaS Applications

When an agent calls external platforms like CRMs, ticketing tools, or ERPs through a single global service account, it inherently sees more than any individual employee should.

AWS recommends an "on-behalf-of" token exchange: swap the authenticated user's identity for a temporary, user-scoped token accepted by the target SaaS. This preserves the external platform's native role and sharing rules. You avoid storing per-user credentials inside the agent, and you avoid prompting users with re-authorization popups for every routine tool call.

Build an Authorization Relay Card for Every Workflow

This is not just an AWS implementation detail; it is a universal design principle for enterprise agents. Before rolling out workflows that retrieve data or trigger actions across systems, establish an authorization relay card that defines:

• The initiator's identity.
• The end user or entity the task serves.
• The specific scope attributes carried across boundaries.
• The exact layer where downstream validation occurs.
• The expiration window for temporary tokens.
• Approval owners for read and write operations.
• Fallback messaging and human escalation paths when access is denied.

Starbox AI uses an Organization → BOX → Agent architecture to support this unbroken chain of authorization:

1. The Organization layer defines roles, data ownership, and escalation protocols.
2. The BOX layer houses customer journeys, field dictionaries, data classification, registered tools, and approval rules.
3. The Agent layer carries only the context required for the immediate task, operating strictly within authorized limits to retrieve, generate, or execute.

The Starbox DDABC closed loop then feeds permission denials, manual overrides, misconfigurations, and edge cases back into the system, refining policies for the next run.

This setup is far more dependable than stacking instructions that tell an LLM "do not leak confidential data." Prompt-level rules assume the model will always understand boundaries correctly. System-level authorization assumes the model will eventually make mistakes, and ensures the underlying door remains locked when it does.

When connecting AI agents to production data, stop asking whether the agent has access. Ask whose identity it carries, what scope it retains, and where its permissions are verified next. Source: AWS Security Blog, "Propagate user authorization context in AI agents with Amazon Bedrock AgentCore" (August 19, 2026).