Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does AWS Bedrock Keep Company Credentials Away From Agents?

Partly: AgentCore Identity keeps long-lived secrets in a token vault and out of agent code, but AWS's documentation says the provider gives the agent the access tokens it needs, so a live credential reaches the agent. Check which tokens the agent receives, how Policy gates their use, and what the agent reads on screen through the Browser tool.

A protected data store releases scoped credential tokens through a filter toward an agent node and application screen.

Partly: AgentCore Identity keeps long-lived secrets in a token vault and out of agent code, but AWS's documentation says the provider gives the agent the access tokens it needs, so a live credential reaches the agent. Check which tokens the agent receives, how Policy gates their use, and what the agent reads on screen through the Browser tool. The question has two halves. The first is whether the agent's code and configuration contain secrets, and here AWS's design improves on the common practice of pasting API keys into environment variables: AgentCore Identity centralizes credentials in a vault and the agent fetches what it needs at runtime. The second is whether the agent, at runtime, holds a credential it could misuse or leak, and it does, by design, because an access token is what lets it call the tool. A vault moves the secret from a file to a service; it does not remove it from the agent's hands at the moment of use. This page works through what AgentCore Identity keeps away from the agent, what the agent still receives, how AgentCore Policy constrains a token's use, what the older return control pattern changes, and what none of these reach: the credentials and sensitive values an agent reads on screen when it operates a web application through the AgentCore Browser tool. The distinction between protecting a stored secret and protecting what an agent reads is drawn in whether a credential vault can protect what an AI agent reads.

Key findings

  • AWS's AgentCore Identity documentation states that centralized credential management eliminates the need to embed secrets in agent code or configuration files (AWS, 2026).
  • The credential provider documentation states that the provider stores the resulting credentials in the token vault and provides the agent with the necessary access tokens, so a usable token does reach the agent (AWS, 2026).
  • AWS's security blog describes the token vault as built to securely store OAuth 2.0 access and refresh tokens, API keys and OAuth 2.0 client secrets, with the agent retrieving them using its own workload token (AWS, 2025).
  • AgentCore Policy intercepts all agent traffic through AgentCore Gateways and evaluates each request before tool access, and temporal rules can require that an approval was granted before a transfer (AWS, 2026).
  • AWS's Well-Architected Agentic AI Lens calls for audit logs that attribute every action unambiguously to either an agent or a human actor (AWS, 2026).
  • OWASP's secrets management guidance treats a secret in a running process's memory as exposed to that process, which is the condition a runtime access token creates for an agent (OWASP, 2024).

What does AgentCore Identity keep away from the agent?

Start with what the design gets right. AWS states that centralized credential management eliminates the need to embed secrets in agent code or configuration files (AWS, 2026). The AWS security blog describes a token vault built to securely store OAuth 2.0 access and refresh tokens, API keys and OAuth 2.0 client secrets, with the agent retrieving them using its own workload token (AWS, 2025). AgentCore is described by AWS as a set of services for deploying and operating agents, with Identity handling who the agent is and what it may fetch (AWS, 2025).

Three things are kept away from the agent. Long-lived secrets, such as client secrets and refresh tokens, stay in the vault rather than in the agent's repository, so a leak of the code does not leak the credential. The agent's identity is a workload token issued to it, not a shared human credential. And the exchange of a long-lived secret for a short-lived access token happens in the vault, so the agent never handles the material that would let it mint new tokens.

OWASP's secrets management guidance describes exactly this pattern as the goal: secrets held in a dedicated store, fetched at runtime by an authenticated workload, never written into source (OWASP, 2024). Against the baseline of agents built with keys in environment variables, AgentCore Identity is the right architecture. The vault keeps the durable credentials away; the next section is about the one it hands over.

What does the agent still receive?

AWS's credential provider documentation states that the provider stores the resulting credentials in the token vault and provides the agent with the necessary access tokens (AWS, 2026). The vault keeps the credentials, and the agent gets the tokens. An access token is a credential: scoped and short-lived, which limits the damage, but for its lifetime it lets its holder do whatever it permits, and the holder is the agent.

Consider a single record type: a billing account page in a SaaS vendor's administrative console, which the agent must read to reconcile an invoice. The agent fetches an access token for the vendor's API from the vault and calls the API. For the token's duration, the agent's process holds a credential that can read, and depending on scope write, the organization's billing account; if the agent is steered by content it read earlier, the token is what the steering would use. OWASP's guidance treats a secret in a running process's memory as exposed to that process; the vault has shortened and scoped the exposure, not removed it.

Dimension AWS, per its documentation What a buyer should verify
Secrets in code No need to embed secrets in agent code or configuration That no agent still carries keys in environment variables
Vault contents OAuth access and refresh tokens, API keys, client secrets Which credentials were left outside the vault
What the agent receives The necessary access tokens The scope and lifetime of each token an agent can fetch
Values read on screen Not described in the pages reviewed What the agent reads on each page it operates through the Browser tool

AgentCore Identity keeps the organization's durable credentials away from the agent and gives it a temporary one. That is the correct trade for an agent that must call tools, and it is a credential in the agent's hands all the same. What limits the token's use is Policy's job.

How does AgentCore Policy constrain what a token can do?

AWS documents AgentCore Policy as intercepting all agent traffic through AgentCore Gateways and evaluating each request before tool access is granted (AWS, 2026). This is the control that addresses the token in the agent's hands: the agent may hold a credential for the billing API, but every call it makes through the Gateway is checked against policy before it proceeds. The same documentation describes temporal rules that can require that an approval was granted before a transfer, which is a documented mechanism for putting a human step in front of a consequential action.

That is a meaningful control, and its scope matters. Policy evaluates traffic that passes through AgentCore Gateways. Whether it reaches a tool the agent calls by another path, a direct HTTP call from its own code or an action taken through a browser, is not described in the pages reviewed, and a buyer should assume it does not until the documentation says otherwise. The approval rule is also conditional in form: it can require that an approval was granted, and the pages reviewed do not say who grants it or how the approver is identified.

The pattern of a gateway that evaluates each request before a credential is used matches the structure described in how to secure agents across AWS, Azure and GCP: the environment, not the model, holds the keys and decides each use. AgentCore Policy implements that structure for Gateway traffic. The remaining questions are what happens on the paths it does not cover, and what the agent reads rather than calls.

What does the return control pattern change?

Bedrock Agents offer a different answer to the credential question. The Bedrock user guide documents RETURN_CONTROL, in which the agent hands the elicited parameters back to the application in the InvokeAgent response, and the application runs the call (AWS, 2026). The agent never holds a credential for the downstream system. It decides what should be done; the application, with its own credentials and checks, decides whether to do it.

For the billing account example, the agent would output the reconciliation parameters and the application would make the API call, so the agent's process never contains the billing token. That is a stronger answer to the title question than the vault, at the cost of putting the integration work on the application developer. It also creates a seam where a human can be inserted, because the application can hold the parameters until someone approves them, which is the design described in keeping consequential actions with a named person.

The patterns answer different needs. Return control suits a small number of well-defined actions the application can own. AgentCore Identity and Policy suit agents that call many tools dynamically, where the agent must hold a token and the Gateway checks each use. A buyer should know which pattern each agent uses, because "AWS keeps credentials away from the agent" is true of return control and only partly true of the vault. The Well-Architected Agentic AI Lens, which asks that agent and human permissions be separated and that audit logs attribute every action unambiguously to an agent or a human, applies to both (AWS, 2026).

What about credentials and values the agent reads on screen?

The controls above concern credentials the agent uses to call tools. AWS also documents the AgentCore Browser tool, which lets an agent interact with web applications through a browser (AWS, 2025). An agent using it does not call the billing API; it opens the vendor's console, signs in and reads the billing account page as a person would, and everything on that page is model input: the account identifier, the stored payment method's last digits, the billing contact's details, and, on many administrative consoles, API keys and webhook secrets displayed in settings.

Here the title question changes shape. The agent is not holding a token the vault issued; it is reading credentials and sensitive values the application rendered. Nothing in the AgentCore Identity or Policy documentation reviewed describes controlling what the agent reads on a page. Identity governs what the agent can fetch from the vault; Policy governs calls through the Gateway. A settings page showing an API key in clear text is neither. Whether the Browser tool itself redacts or masks on-screen values before the model reads them is not described in the pages reviewed.

The general problem is laid out in what AI agent credential protection covers: a vault protects credentials the organization stores, while an agent operating a browser encounters credentials the applications display, and the second set is as sensitive as the first. AgentCore addresses the first set with a sound design; the pages reviewed do not address the second. An organization using the Browser tool against administrative consoles should treat every page as potentially containing a secret the model will read.

What does a governed environment change?

In a governed environment, the credentials and secrets displayed on the pages an agent operates are replaced before the model reads them, which closes the gap that AgentCore Identity and Policy leave open on the Browser tool: the screen.

The mechanism is a class of control applied to the rendered page rather than to the tool call. Sensitive values on the screen, including API keys, payment details and customer records that happen to be displayed, are replaced with consistent tokens before any model reads them, so the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This matters here because the two statements the previous section said to refuse both concern what reaches the agent. AWS's documentation says the credential provider gives the agent the necessary access tokens (AWS, 2026), and OWASP treats a secret in a running process's memory as exposed to that process (OWASP, 2024). A governed environment does not alter that runtime token, but it does remove the second route to a credential, the one displayed on a page the agent browses, which the pages reviewed do not address. The approval record also supplies the unambiguous attribution to a named human that the Well-Architected lens requires.

The control does not change AgentCore Identity, Policy or the model, and it covers the rendered page, not the token vault, the Gateway or the agent's runtime memory.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design addresses the row AgentCore Identity and Policy leave open: what the agent reads on a rendered screen. Work runs in a governed environment in the customer's cloud. When an agent opens a billing account page, an administrative console or a settings screen, substitution happens at the render layer before any model reads the screen, so identifiers appear to the model as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, and a displayed API key or payment detail is a token rather than a value the model holds. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged, so it sits beside a vault for stored credentials rather than replacing it.

Deployments are in pilot. For this page's question, a pilot on the reader's own browser workflow would show, page by page, which displayed values the model received as tokens, which it never needed, and which actions reached a named approver, giving the organization a record for screen-read values to set beside the vault's record for fetched tokens. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on AWS's own documentation: the AgentCore Identity features page, the credential provider configuration page, the AgentCore Policy page, the AgentCore overview, the AgentCore Browser tool page, the Bedrock user guide page on return control, and the Well-Architected Agentic AI Lens best practice on separating agent and human permissions (vendor documentation and guidance), together with the AWS Security Blog post introducing AgentCore Identity (vendor blog). It also draws on the OWASP Secrets Management Cheat Sheet (industry standard). All sources were read as of October 16, 2026.

No hands-on testing of Amazon Bedrock, Bedrock Agents, AgentCore Identity, AgentCore Policy, AgentCore Gateway, the AgentCore Browser tool or any AWS account was performed for this page. "Not described in the pages reviewed" concerns the documentation consulted, not a claim that the product lacks a capability; AWS may document Policy coverage of non-Gateway paths or Browser tool masking in material not reviewed. AWS documentation for AgentCore changes frequently as the service develops, and the page carries its date for that reason. Statements about RedactSure describe its current design, with deployments in pilot. The billing account page, administrative console and settings page examples describe record types and screens, not any organization or vendor; no customer or prospect is described.

Whether a given agent's credential handling, Policy configuration and Browser tool use satisfy an organization's obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

AWS documents a sound credential architecture for agents that call tools: long-lived secrets stay in a token vault, the agent authenticates with its own workload token, and the provider gives the agent the access tokens it needs, with AgentCore Policy evaluating each request through a Gateway and able to require an approval before a transfer. The agent therefore holds a live, scoped credential at runtime by design; the older return control pattern is the one in which it holds none. What the pages reviewed do not address is the agent that operates a web application through the Browser tool and reads whatever the page displays, including credentials and sensitive values the vault never issued. The test is to name one agent and one tool and ask which path it authenticates by, whether its calls pass through Policy, and, if it uses the Browser tool, what the last page it read contained.

Frequently asked questions

Does the agent ever hold a credential under AgentCore Identity?

Yes, a short-lived one. AWS's credential provider documentation states that the provider stores the credentials in the token vault and provides the agent with the necessary access tokens. Long-lived secrets stay in the vault. The access token the agent receives is scoped and temporary, which limits exposure, but for its lifetime the agent's process holds a usable credential for the downstream system.

What does the token vault protect against?

Secrets in code and configuration. AWS states that centralized credential management eliminates the need to embed secrets in agent code or configuration files, and the vault is described as storing OAuth access and refresh tokens, API keys and client secrets. A leak of the agent's repository therefore does not leak the durable credentials, and the agent cannot mint new tokens on its own because the material for that stays in the vault.

How does AgentCore Policy limit what an agent does with a token?

AWS documents Policy as intercepting all agent traffic through AgentCore Gateways and evaluating each request before tool access, with temporal rules that can require that an approval was granted before a transfer. The control applies to calls that pass through a Gateway. Whether it reaches tools the agent calls by other paths, or actions taken through a browser, is not described in the pages reviewed and should be confirmed per tool.

Is return control more protective than the vault?

For the credential question, yes. Under RETURN_CONTROL the agent hands the elicited parameters back to the application, which runs the API call with its own credentials, so the agent never holds a token for the downstream system. The cost is that the application owns each integration and the pattern suits a smaller set of well-defined actions. The vault pattern suits agents that call many tools dynamically, at the price of a token in the agent's hands.

Does AgentCore protect credentials an agent sees on a web page?

Not in the pages reviewed. AgentCore Identity governs what the agent fetches from the vault and Policy governs calls through the Gateway. When an agent operates a web application through the AgentCore Browser tool, it reads whatever the page displays, which on administrative consoles can include API keys, payment details and customer records. Whether the Browser tool masks on-screen values before the model reads them is not described in the pages reviewed.

What should an organization check first?

How each agent authenticates to each tool: vaulted through AgentCore Identity, handled through return control, or still carrying keys in configuration. Fix the third category first. Then confirm which tool calls pass through a Gateway and are evaluated by Policy, who grants any required approvals, and whether the audit log attributes each action to an agent or a person. Finally, list what every page an agent operates through the Browser tool displays, since neither Identity nor Policy governs what the model reads there.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.