Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Checking Credentials Stop an AI Agent From Taking Unauthorized Actions?

No, because a credential check proves whose session the agent is using, not that the action it is about to take was intended by that person. Check whether your deployment adds a decision between authentication and action, since an agent with valid credentials is the textbook confused deputy.

A credential checkpoint opens onto several possible action paths with separate destination doorways.

No, because a credential check proves whose session the agent is using, not that the action it is about to take was intended by that person. Check whether your deployment adds a decision between authentication and action, since an agent with valid credentials is the textbook confused deputy. The question comes up because most organizations have invested in identity: single sign-on, multi-factor authentication, privileged access management. Those controls answer "who is this?" very well. An AI agent passes them in the same way a person does, and once it has passed them, every action it takes is authorized in the only sense the identity system understands, because it is taken within a valid session. This page separates what a credential check proves from what it does not, explains why an authenticated agent is the confused deputy that access control literature has described for decades, shows how a logged-in session turns page content into authority, records what financial regulators now say about agents exceeding their intended scope, identifies the control that is missing between authentication and action, and sets out what a buyer should refuse to accept. It builds on action governance for AI agents: the session is the agent's permission to be present, not its permission to do any particular thing.

Key findings

  • AWS defines the confused deputy problem as the situation in which "an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action," which is the position an authenticated agent occupies whenever it reads untrusted content (AWS, 2026).
  • Once an agent follows injected instructions inside a logged-in browser, Brave's researchers found that "same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless," because the agent carries the user's authority across every site (Brave, 2025).
  • FINRA's 2026 oversight report flags that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2025).
  • OWASP's LLM06:2025 entry defines excessive agency as a model granted more functionality, permissions or autonomy than its task requires, which is what a valid credential confers when it carries the user's full access (OWASP, 2025).
  • NIST's zero trust model evaluates each access request at a policy enforcement point rather than trusting a session once established, which is the shape of the per-action control an agent needs (NIST, 2020).
  • Agent frameworks now expose the hook for that control: OpenAI's Agents SDK documents a human-in-the-loop pattern in which a run pauses for approval of specific tool calls before they execute (OpenAI, 2025).

What does a credential check actually prove?

That the party presenting the credential controls the authenticator. NIST's Digital Identity Guidelines describe authentication as the process of establishing confidence that a claimant is the subscriber it claims to be, with assurance levels that depend on the strength of the authenticators used (NIST, 2025). A password, a hardware key and a one-time code each raise that confidence. None of them says anything about what the authenticated party intends to do next, and none of them distinguishes a person typing from an agent operating with that person's session.

Authorization is the separate question: given who this is, what may they do? Most enterprise applications answer it with roles. A claims adjuster can approve payments up to a limit; a billing clerk can issue refunds; an administrator can change settings. When an agent signs in as the adjuster, it inherits the adjuster's role, and the application has no further question to ask. Every payment under the limit is permitted. The application cannot tell whether a given payment was the one the adjuster asked for or one an injected instruction asked for, because it never had a model of intent, only a model of role.

Consider a refund screen in a billing system. The agent's task is to issue one refund for a disputed charge on one customer account. The credential check confirms the session belongs to the clerk, and the role check confirms the clerk may issue refunds. If the agent then issues three refunds, or issues the right refund to a different account, no credential or role check fails. The action is unauthorized in the ordinary sense of the word and fully authorized in the system's sense, and the gap between those two meanings is the subject of this page (What Is AI Agent Credential Protection?).

Why is an authenticated agent a confused deputy?

Because it acts on instructions from parties who do not hold its privileges. AWS's IAM documentation defines the confused deputy problem as the case in which "an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action" (AWS, 2026). An AI agent fits the definition exactly. It holds the user's privileges, it reads content written by people who do not, and it treats that content as input to its decisions.

The coercion does not need to be sophisticated. An agent processing a support ticket reads the ticket text. If the text says to close the account and issue a credit, the agent may do so, and the billing system sees a request from an authenticated clerk with a valid role. The ticket author had no permission to close accounts. The agent did. The agent could not tell the difference between its principal's instruction and the ticket's, which is the confusion in the name. OWASP's LLM01:2025 entry describes prompt injection as the class of attack that exploits this: content that a model processes as data is crafted to be processed as instruction (OWASP, 2025).

The remedy in the IAM world is well known. The deputy must carry, with each request, evidence of which principal the request is really for, so that the privileged system can check the request against that principal's permissions rather than the deputy's. For an agent, the equivalent is a decision, made outside the model and attached to each consequential action, that confirms the action was intended by the person whose session is in use. A credential check establishes the deputy's identity; it cannot establish that the deputy is not confused (What Is AI Agent Action Governance?).

How does a logged-in session turn page content into authority?

By removing the boundaries that normally separate one site's content from another site's permissions. Brave's analysis of indirect prompt injection in an agentic browser describes the result: once an agent follows injected instructions in a logged-in browser, "same-origin policy (SOP) or cross-origin resource sharing (CORS) are all effectively useless" (Brave, 2025). The browser's security model assumes that a page can only act within its own origin. An agent reading that page and then acting in another tab, under the user's authenticated session, has carried the page's instruction across the boundary the browser was built to enforce.

The same mechanism applies inside the enterprise. A customer record contains free-text notes. A shared document contains a comment. An internal wiki page contains a table. Each of these is content the agent reads in the course of its task, each was written by someone who is not the agent's principal, and each becomes a candidate instruction the moment the model processes it. The agent's credentials are valid for every system it visits afterward, so an instruction planted in one record can be executed in any other.

Layer What it checks What it cannot see
Authentication That the session belongs to a known user Who wrote the instruction the agent is following
Role-based authorization That the user's role permits this class of action Whether this specific action was the one the user intended
Browser origin controls That a page acts only within its origin An agent carrying one page's instruction into another's session
Per-action approval That a named person confirmed this action on this record Nothing in this list; it is the missing layer

The table makes the point that each existing layer answers a question the next one does not. Credential checking is the first row. The attack operates at the fourth.

What do regulators say about agents acting within valid credentials?

They have begun to name the gap directly. FINRA's 2026 Regulatory Oversight Report, as summarized by Debevoise & Plimpton, flags that "Agents may act without human validation and may take actions that exceed the user's actual or intended scope or authority" (Debevoise & Plimpton, 2025). The phrase "intended scope or authority" is the regulator's version of the distinction this page draws: the agent may be within its credentialed authority and outside its intended one at the same time, and the regulator treats the second as the one that matters.

That framing has consequences for how a firm demonstrates control. An identity program that shows every agent session was authenticated with strong factors answers a question FINRA did not ask. The question asked is whether a human confirmed the action, and whether the action stayed within what the user meant. Evidence for that comes from a record of the actions proposed, the approvals given and the people who gave them, not from the authentication log.

OWASP's LLM06:2025 entry on excessive agency gives the same concern a technical name. It describes the risk of a model that has more functionality, permissions or autonomy than its task requires, and lists among its mitigations limiting the permissions an agent holds and requiring human approval for high-impact actions (OWASP, 2025). A valid credential that confers the user's full access is excessive permission by that definition whenever the task needs less, which is nearly always. The regulator and the standard arrive at the same place: the credential is the beginning of the control question, not the answer to it.

What control is missing between authentication and action?

A decision, made per action, by a party the attacker cannot address. NIST's zero trust architecture describes the general shape: access to a resource is evaluated for each request at a policy enforcement point, with trust never assumed from a prior session or network location (NIST, 2020). Applied to agents, the resource is the consequential action, the request is the agent's proposal to take it, and the enforcement point is a step that confirms the proposal matches the principal's intent before anything executes.

Agent frameworks have begun to expose this step. OpenAI's Agents SDK documents a human-in-the-loop pattern in which a run pauses when the agent proposes certain tool calls, surfaces them for approval, and continues only with the approved ones (OpenAI, 2025). The pattern is the right one. Its value depends on three implementation choices: which actions require approval, what the approver sees, and whether the approval is recorded with the approver's name.

The first choice decides coverage. Payments, submissions and record changes are the actions whose reversal is costly and whose misuse is the point of most attacks, so they are the ones that must pause. The second decides whether the approval is meaningful: an approver shown "process refund" learns nothing, while one shown the account, the amount and the destination can catch a redirected payment. The third decides whether the organization can later show who allowed what. A person approving an action should also not be the one exposed to the sensitive values on the screen more than the task requires, which is why approval pairs naturally with substituting tokens for sensitive data before the model and the approver see it (Can a Credential Vault Protect What an AI Agent Reads?).

What does a governed environment change?

In a governed environment, a decision is inserted between authentication and action: the agent's valid credentials still open the session, but a consequential action waits for a named person who sees what the environment will do rather than what the model says it will do.

The mechanism is a class of control that treats the session as necessary and insufficient. Sensitive values on the rendered page are replaced with consistent tokens before any model reads them, so the agent works on tokens and an injected note has fewer real values to redirect. 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, including payments, refunds, submissions and record changes, from a proposal built by the environment, not the model's summary. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging, so the record names who approved and not only whose session was used.

This is the control the previous section said was missing. The confused deputy acts within its permissions every time (AWS, 2026), and once an agent follows injected instructions inside a logged-in browser, same-origin and CORS protections are effectively useless (Brave, 2025). The demonstration asked for above, a third-party note followed by a consequential action, is the case this class of control exists for: the proposal reaching the approver reflects the task, and if the note has steered the agent the approver sees the divergence and refuses.

The control does not change the application, the user's permissions, the authentication method or the model; it adds the decision a credential check was never designed to make.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design adds the missing decision between authentication and action, and governs what the model sees while it works. The agent operates inside a governed environment in the customer's cloud under the user's existing permissions, which are left unchanged. Substitution happens at the render layer before any model reads the screen, so the refund screen or customer account reaches the model with sensitive values as consistent tokens such as ACCT_001 or PATIENT_001 for the whole run, and 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 before it executes, which RedactSure calls Supervised Delegation, so a proposal that originated in a ticket rather than the task reaches a person who can refuse it. 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 and requires no per-application integration.

Deployments are in pilot. A pilot on the reader's own workflow would show an agent with valid credentials proposing an action, the person who saw and approved it, and the record that distinguishes an intended action from one a page suggested. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on vendor documentation, standards and official guidance, security research and a regulatory summary: AWS's IAM User Guide entry on the confused deputy problem, OpenAI's Agents SDK documentation on human-in-the-loop approval, Brave's published analysis of indirect prompt injection in an agentic browser, NIST Special Publication 800-63-4 on digital identity and Special Publication 800-207 on zero trust architecture, OWASP's LLM01:2025 and LLM06:2025 entries, and Debevoise & Plimpton's summary of FINRA's 2026 Regulatory Oversight Report. All sources were read as of October 16, 2026. The FINRA report is quoted through the law firm summary cited, not from the primary document, and the NIST publications are cited for the definitions their titles cover rather than for any finding about agents.

No hands-on testing of any product was performed. Where this page says a capability is "not described," it means not described in the pages reviewed, not that the capability is absent. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot, and are confined to the section on where the company sits. The refund screen, support ticket and customer account examples describe record types, not any organization; no customer or prospect is described.

Whether a given deployment's authentication, authorization and approval arrangements satisfy a regulator's expectation of human validation, an organization's security policy or its contractual obligations is a determination for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Checking credentials does not stop an AI agent from taking unauthorized actions, because the check answers a different question. Authentication establishes whose session the agent is using; role-based authorization establishes which classes of action that session permits; neither establishes that a particular action was the one the person intended. An agent that reads content written by others and acts on the user's authority is the confused deputy of access control literature, and FINRA now describes the resulting risk as actions that exceed the user's actual or intended scope. The missing control is a per-action decision, made by a named person who sees the account, amount and destination, recorded before the action executes. The test is to name one agent and one task and ask: when a note on the record tells the agent to do something else, who sees the proposal before it lands, and what do they see?

Frequently asked questions

If the agent passed multi-factor authentication, is it not already authorized?

It is authenticated, which establishes that the session belongs to a known person. Authorization in the application's sense follows from that person's role. Neither step examines whether the specific action the agent proposes was intended by that person or suggested by content the agent read. Strong authentication is worth having, and it makes the session harder to steal, but it leaves the question of intended versus suggested actions entirely open.

What is the confused deputy problem in plain terms?

A trusted party that acts on behalf of others can be tricked by one of them into using its privileges for that person's benefit. AWS defines it as an entity without permission coercing a more privileged entity to perform the action. An AI agent is a deputy for its user, holds the user's privileges, and reads instructions written by people who do not hold them. When it follows one of those instructions, it is the confused deputy acting within its permissions.

Does the application's own permission model protect against this?

Only to the extent that the agent's role is narrower than the attack requires, and roles are usually broad because they were designed for people. A billing clerk's role permits refunds; an attacker who wants a refund needs nothing more. The permission model assumes a human reads a ticket and decides. It has no way to distinguish a decision from compliance with the ticket, so a model that may obey what it reads needs a control the role model does not provide.

Why does a logged-in browser make the problem worse?

Because the agent carries the user's authority across every site and tab. Browser security assumes a page can act only within its own origin. Brave's researchers found that once an agent follows instructions from one page and acts in another under the user's session, same-origin and cross-origin protections become effectively useless. The agent is the bridge the browser's security model never anticipated, and credentials valid everywhere make every destination reachable.

What should a per-action approval show the approver?

Enough to catch a substitution. An approver shown only the action type learns nothing useful. An approver shown the record, the amount and the destination can notice a payment redirected to a new account or a refund issued to the wrong customer. The approval should be given before the action executes, not after, and should be recorded with the approver's name so that the organization can later show who confirmed what.

Does per-action approval slow every task to a crawl?

Not if it is scoped to consequential actions. Reading, searching and drafting do not need approval; payments, submissions and record changes do. Most tasks involve many of the former and few of the latter, so approval pauses arrive at the points where a mistake would be costly to reverse. OpenAI's Agents SDK documents this pattern, pausing a run for approval of specific tool calls, which shows the mechanism is available at the framework level.

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.