Who is accountable when an AI agent approval screen is exposed to unauthenticated users?

The application team is accountable, because the product chose where and how to display the approval code. The identity provider can enforce matching on the backend, but it cannot prove that the person viewing the screen is authenticated. Teams should gate the screen behind the same signed-in controls that protect the rest of the product.

Why This Matters for Security Teams

An approval screen exposed to unauthenticated users is not just a UI bug. It breaks the trust boundary around an AI agent workflow, where the screen may reveal approval codes, decision context, or operational controls that an attacker can reuse. The accountability issue matters because backend identity checks cannot compensate for a product decision that makes a sensitive action visible before the user is authenticated.

This is especially important in agentic systems because the screen is often part of a broader execution path: a human approves, the agent proceeds, and the resulting action may touch secrets, APIs, or downstream tools. Guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point practitioners toward runtime controls, ownership clarity, and least privilege rather than trust in a single compensating control. NHIMG research on the OWASP Agentic Applications Top 10 reinforces that agent workflows fail when access decisions and presentation layers are not aligned.

In practice, many security teams encounter this only after an exposed approval flow has already leaked a code or allowed an unauthenticated user to trigger the next step.

How It Works in Practice

Accountability follows control of the application path, not the identity provider alone. If the product renders an approval screen, it owns the decision to expose that screen and must require the same signed-in state that protects the rest of the workflow. The identity provider can validate tokens, session state, and backend assertions, but it cannot prove that the person looking at the page is authenticated if the page is publicly reachable.

For agent approvals, the practical pattern is to split the problem into three checks: authenticated presentation, backend authorization, and scoped agent action. The screen should only load after session validation. The backend should verify that the user is allowed to approve that specific agent request. The approval token or code should be short-lived, bound to the request, and invalidated after use. That is consistent with current guidance from CSA MAESTRO agentic AI threat modeling framework, which treats the approval path as part of the threat surface, and with NHIMG coverage in Analysis of Claude Code Security, where tool gating and execution authority must be tightly coupled.

• Require authentication before any approval screen is rendered.
• Bind approval codes to a specific session, request, and expiration time.
• Enforce server-side authorization for the exact action, not just the page view.
• Log who saw the request, who approved it, and whether the session was fresh.

This is where teams often fail in split architecture environments, because the frontend is public while the approval API assumes the user interface already handled authentication.

Common Variations and Edge Cases

Tighter approval gating often increases friction for users and support teams, so organisations must balance usability against exposure risk. The right balance depends on whether the screen is merely informational or whether it discloses an active approval token, agent command, or privileged workflow step.

There is no universal standard for this yet, but current guidance suggests treating any approval-related screen as sensitive by default. Public demo environments, shared support portals, and embedded widgets are common exceptions that create false confidence. In those cases, a page may appear harmless while still exposing identifiers that can be replayed against the backend. NHIMG research on The State of Secrets in AppSec shows how quickly sensitive material becomes operationally risky once it leaves its intended boundary; similar logic applies when approval artifacts are exposed outside authenticated flows.

For high-risk agent workflows, best practice is evolving toward ephemeral approvals, context-aware checks, and zero standing access to the approval surface itself. That is consistent with broader zero trust thinking and with OWASP and NIST guidance. The key exception is read-only operational visibility: if a screen contains no approval secret, no action trigger, and no sensitive decision context, the exposure risk is lower, but it still warrants review. In practice, approval screens most often become incidents in staging-to-production copy paths or customer support consoles where authentication assumptions drift from the original design.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?