Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Can a Browser Agent See in My AWS Console?

Everything the console renders for the role it signed in with: access key IDs and a newly created credential on the IAM security credentials page, Secrets Manager values once opened, account IDs and billing figures. Before the first run, decide which values the model needs and move the rest behind a role, a vault or a token.

A credential reference travels from a browser record through a bounded route to a separate API destination.

A browser agent signed into the AWS console reads whatever the console draws for that session, and the console draws a great deal: the access key list on a user's security credentials page, the secret access key of a key pair at the moment it is created, the plaintext of a credential in Secrets Manager once someone clicks to reveal it, the account ID in the corner of every page, and the month's spend on the billing dashboard. The console was designed for a person, and a person is not expected to retain any of that. A model retains all of it in context, where it can be repeated, logged or written into a file. This page takes one record type, the IAM security credentials page for a single user, and follows what an agent sees there and after: the scope of a browser control, what AWS and GitHub document, how a console view differs from a credential the agent was handed, where a value goes once read, what to change before the first run, and what a governed environment adds. What Can an AI Agent See in Your GitHub Settings? applies the same method to a repository settings page, and Is It Safe to Let an AI Agent Set Up Your Cloud Environment? takes the wider question of agent-built infrastructure.

Key findings

  • AWS documents AssumeRole as returning "a set of temporary security credentials that you can use to access AWS resources," with a session that "can range from 900 seconds (15 minutes) up to the maximum session duration set for the role," so a credential handed to an agent can expire; a key read off a console page does not (AWS, AssumeRole, 2026).
  • AWS describes Secrets Manager as replacing "hard-coded credentials with a runtime call to the Secrets Manager service to retrieve credentials dynamically when you need them," which keeps a credential out of code and does not keep it off a console page that an agent opens (AWS, What, 2026).
  • Datadog found that "37 percent of customers who send CloudTrail logs to Datadog are using IAM users in their GitHub Actions," which means long-lived keys of the kind the IAM page lists remain common in pipelines (Datadog, 2025).
  • Research on code completion tools found that "two valid credentials were identified during our experiments" by prompting models to reproduce training data, which shows a credential that enters a model's inputs can come back out (Huang et al., Your, 2024).
  • A governed environment that replaces values with consistent tokens before any model reads the screen means the agent working an IAM page sees a placeholder where the key would be (What Is Render-Layer Tokenization?).
  • Real values resolve only at the approved destination at the moment of an approved action, so a key can be created, stored and used without the model ever holding the string (What Is the PII Wall?).

What does a browser agent see when it opens the console?

The scope of this page is the browser. A governed browser environment covers what an agent reads and does on a rendered page, which includes dashboards, consoles, settings pages and sign-up forms. It does not cover the terminal, the IDE, the local filesystem, direct API calls or MCP. An agent that runs the AWS CLI in a shell, or calls the API through an SDK, is outside this page, and nothing here implies that a browser control governs a shell.

Inside that scope, the answer is the rendered page. The record type here is the IAM security credentials page for one user. It lists the user's access key IDs with their status and age. When a new key is created, the console shows the secret access key once and offers it for download, and an agent that reads the page at that moment has both halves of a long-lived credential in context. The same session reaches the Secrets Manager console, where a credential's value is hidden behind a reveal control until someone, or something, clicks it. It reaches the account ID shown on every page, the billing dashboard, the list of users and roles, and any trust policy that names an external account.

None of that is a defect in the console. A person reading the page is trusted not to transcribe the credential into a chat log, and the console was built on that trust. An agent's model receives the page as text, and text in context is retained for the run and can be repeated in output, written to a file or sent to a tool. The question the rest of this page answers is which of those values the task needs, and which of them the model received only because the page drew them.

What do the vendors themselves say?

AWS documents AssumeRole as the way to issue a scoped, expiring credential: the session's permissions "are the intersection of the role's identity-based policy and the session policies," and "role chaining limits your AWS CLI or AWS API role session to a maximum of one hour" (AWS, AssumeRole, 2026). The page describes credentials issued to a caller, not what a console renders to a signed-in session.

AWS's Secrets Manager guide says a team can "configure an automatic rotation schedule for your secrets" (AWS, What, 2026). Rotation shortens the life of a leaked value; a role that retrieves a credential still hands it to whatever process called, including an agent.

AWS's AgentCore Identity documentation says "centralized credential management eliminates the need to embed secrets in agent code or configuration files" (AWS, Features, 2026), and its credential provider page states that the provider "stores the resulting credentials in the token vault, and provides the agent with the necessary access tokens" (AWS, Configure, 2026). The agent still receives a usable token, and the vault governs API credentials, not values on a page the agent reads. The AWS Security Blog describes the vault as built to "securely store OAuth 2.0 Access and Refresh tokens, API keys, and OAuth 2.0 client secrets," retrieved with the agent's own workload token (Douglas III and Abrom, 2025). A control over what a model is shown on the IAM page is not described in the pages reviewed, and a buyer should verify whether the agent runs under a role or a user's keys, and who can reveal a value in the console.

How does a console view differ from a credential the agent was handed?

A credential issued by AssumeRole has a shape: a scope that is the intersection of two policies, and a lifetime measured in minutes to hours. A key read off the IAM page has neither. It carries the full permissions of the user it belongs to, and it lives until someone deactivates it. The difference matters because the two reach the agent by different routes. The first is given to the agent on purpose, by a person who chose the role. The second is picked up by the agent because the page it was asked to work on happened to display it.

The leak record shows that the second kind is still the common kind. Datadog's 2025 report found that 37 percent of customers sending CloudTrail logs to Datadog "are using IAM users in their GitHub Actions" (Datadog, 2025). Those are long-lived keys of exactly the type the IAM page lists, in a place where a browser agent setting up a pipeline would be sent to paste them. The same report noted that "throughout 2024, Datadog identified thousands of malicious PyPI and npm libraries in the wild," so a pipeline that holds a long-lived key is also a pipeline that installs code from a registry with a known problem.

An agent working through the browser can be given either. A session created through a role, with the console opened under that role, shows the agent only what the role can see, and the credential expires. What Happens When an AI Agent Can See API Keys in a Console or Settings Page? records AWS's own instruction that "IAM users with access keys are an account security risk," and the sibling page on cloud setup records AWS's recommendation against root access keys. Both push toward the first route. Neither changes what the console renders once the session is open.

Where does a value go once the agent has read it?

Into the model's context first, and from there anywhere the agent writes. A credential that enters a model's inputs is not guaranteed to stay there. Huang and colleagues found that neural code completion tools "can not only return the precise piece of their training data" but, in their experiments, that "two valid credentials were identified" (Huang et al., Your, 2024). That study concerns training data rather than a single session's context, and it is cited here for the principle: a value a model has held can be reproduced later, by a prompt the original owner never wrote.

Within a session, the risks are nearer. Agent Security Bench reports that its "benchmark results reveal critical vulnerabilities in different stages of agent operation" with "limited effectiveness shown in current defenses" (Zhang et al., 2025). An instruction hidden in a page the agent visits can ask it to repeat what it has seen, and a console session that holds a secret access key in context has something worth repeating. The package record adds a third route: Spracklen and colleagues measured hallucinated package names at "at least 5.2% for commercial models and 21.7% for open-source models" (Spracklen et al., 2025), so an agent that moves from the console to a terminal and installs what it names can install something nobody published on purpose.

GitHub's controls catch the value late. Push protection "acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push" (GitHub, Push, 2026), which meets a key that reached a commit and not one that reached a transcript, a log or a configuration file that is never pushed. The value was read on the IAM page some time before.

What should a team change before the first console run?

Start with the route. Run the agent's session under a role assumed through AssumeRole, with a session policy that narrows it and a duration near the documented floor of 900 seconds (AWS, AssumeRole, 2026). The console then shows the agent only what that role can see, and the credential expires. Do not create an access key for the agent on the IAM page, since the page will render it.

Second, move the values the agent must use off the page. Secrets Manager's design is "a runtime call to the Secrets Manager service to retrieve credentials dynamically when you need them" (AWS, What, 2026), so a workload retrieves the credential and the agent never reveals it. Keep the reveal permission off the agent's role.

Third, narrow what the agent can do with what it picks up. GitHub's secure use reference says to set the default GITHUB_TOKEN permission "to read access only for repository contents," to "pin references to actions to a commit SHA in your workflow files," and to "audit how secrets are used, to help ensure they're being handled as expected" (GitHub, Secure, 2026). The audit is what tells a team whether a value was touched. How Do You Let an AI Agent Manage API Keys Without Reading Them? covers the agent never reading the key, and How to Set Up S3 and GitHub With Cowork or Dots uses OIDC so no key is pasted.

Change What it closes What it leaves open
Short role session Long-lived keys What the console renders
Secrets Manager, reveal denied Plaintext credentials on the page Credentials fetched by API
Read-only token, pinned actions, audit Reach of a stolen token The read that put it in context

What does a governed environment change?

A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works on placeholders. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms the tokenization policy and approves each consequential action. Every screen as tokens, every action and every approval is written to a record that exports to the organization's own monitoring.

For this question it covers the console. An agent sent to the IAM security credentials page to create a key for a pipeline reads ACCESS_KEY_01 and SECRET_KEY_01 where the console drew the strings. It can paste the placeholder into a repository secrets form and complete the task. The real value resolves into the secrets form at the moment a named person approves that paste, and nowhere else. The account ID and the billing figures are tokenized the same way if the policy names them. The record shows each page the agent saw, as tokens, and who approved the paste. What Can Claude in Chrome Access in Your Browser? describes a consumer browser agent that sees what is on the page and acts on it, which is the behavior this class governs.

The scope stays the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP. A key retrieved by the AWS CLI or an SDK call is governed by the role and the session, not by the environment.

Methodology and limitations

This page rests on AWS documentation for AssumeRole, Secrets Manager and AgentCore Identity, an AWS Security Blog post, GitHub's push protection and Actions secure use documentation, three research papers, Datadog's State of DevSecOps 2025 report and existing RedactSure research pages. Sources were read as of October 20, 2026. Quoted facts are cited to the page that states them, and the Datadog figures are cited as that vendor reported them from its own customer base, not as independently measured. The description of what the IAM security credentials page and the Secrets Manager console display is a description of the record type as a signed-in user encounters it, and the AWS pages cited do not describe console rendering.

RedactSure did not test a browser agent against an AWS account. "Not described in the pages reviewed" means the pages reviewed and nothing broader. The research papers concern training-data memorization, agent benchmarks and package hallucination in general and are cited for the principle only; none of them tested an agent in the AWS console. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, and RedactSure is deploying now with enterprise and government customers. Examples describe record types, such as one user's security credentials page, and not organizations.

Determinations about whether a configuration meets a legal, contractual or regulatory requirement belong to counsel, assessors and the organization's own security and compliance officers. Nothing here replaces a test on the organization's own account, with a throwaway user and a key that is deactivated afterward, repeated when AWS changes the console or the agent vendor changes its browser.

What the record shows

The documentation answers the question by omission. AWS documents how to issue a short-lived, scoped credential, how to keep a credential out of code and how to hand an agent an access token from a vault, and none of those pages describes what a console page renders to a session that an agent is driving. The leak record shows the long-lived key is still common, and the research record shows a value a model has held can come back out. So what a browser agent sees in the console is whatever the console draws, which includes the secret access key of a new key at creation, and RedactSure's render-layer design is one implementation of the control class that changes the read. The quickest test uses a throwaway user's security credentials page: send one named agent there on one task, create a key, deactivate it, and search the run's transcript and every file it wrote for the string.

Frequently asked questions

Can a browser agent read my AWS access keys?

It can read what the IAM security credentials page renders for the session it is signed into: the list of access key IDs, and the secret access key at the moment a new one is created. The credential is shown once, which is enough for a model that retains the page in context. If the agent must create a key, have the environment replace the value before the model reads it, or create the key by another route and never open the page in the agent's session.

Does Secrets Manager hide values from the agent?

It keeps them out of code, since AWS describes it as replacing hard-coded credentials with a runtime call. It does not hide a value from a console session whose role is allowed to reveal it, and a role that retrieves a credential hands the value to whatever process called it. Deny the reveal and retrieve permissions to the agent's role unless the task needs them, and rotate on a schedule so a value that leaked anyway stops working within days.

Is a role session safer than an IAM user's keys?

Yes, on the two measures AWS documents. A role session's permissions are the intersection of the role's policy and the session policy, and its duration runs from 15 minutes to the role's maximum, with one hour as the cap under chaining. A user's key carries the user's full permissions and does not expire. The role session still shows the agent everything the role can see on each page, so narrow the role before the first run and keep the reveal and key creation permissions out of it.

What can prompt injection take from a console session?

Whatever the model holds in context from the pages it visited. Agent Security Bench reports critical vulnerabilities across stages of agent operation and limited effectiveness in current defenses, so a page the agent reads can carry an instruction to repeat what it has seen. A session that read a secret access key has that string to give up. A session that read a placeholder gives up the placeholder, which is why the control belongs before the read.

Will secret scanning catch a key the agent read?

Only if the key reaches a commit. GitHub's push protection scans code for hardcoded credentials at the time of the push, so it meets a key written into a file that is pushed. It does not meet a key in an agent's transcript, a harness log or a configuration file that stays local, and the read on the IAM page happened before any of those. Keep it on as a late backstop, treat any key it trips on as already exposed, and deactivate that key the same day.

What should a security team ask for in writing?

Ask which role the agent's console session runs under, its session policy and duration, whether that role can reveal Secrets Manager values, and whether the agent's session ever opens the IAM security credentials page. Ask what record shows which pages the model read and which values were on them, and who approved each paste of a credential into another system. Treat a pipeline that still uses an IAM user's keys as the first thing to replace.

About the author

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.

How RedactSure Keeps a Secret Access Key Off the Console Page an Agent Reads

The console renders a new access key once, in full, and the AWS controls reviewed scope, expire or vault it without deciding what the model receives.

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Before: the agent creates a key on the IAM page and the model reads the key ID and the key value in the clear. Inside the governed environment: the page renders with ACCESS_KEY_01 and SECRET_KEY_01, the agent pastes the placeholders into the pipeline's credentials form, and the real values resolve there on a named person's approval.

RedactSure is deploying now with enterprise and government customers. Datadog found that 37 percent of customers sending it CloudTrail logs use IAM users in their GitHub Actions.

Everyone else controls where data can go. RedactSure controls what the AI can see.

See it on your own workflow

The IAM page shows an access key only once, and once is enough for the model to keep it. Bring an AWS key task and see, with test values, what the model reads and where the real key is written. Book a demo

Book a demo

Book a demo

Having trouble? Open the booking page or email us.