They need all three, but none is sufficient on its own. Identity establishes the session, endpoint observes the device, and application controls see the destination. The missing layer is action governance, which decides whether the agent should be allowed to proceed at all. That governance must sit close to execution, not only at login.
Why browser controls are only one part of the decision
Agentic browser control is a layered security problem because the agent is acting through a live user session, on a real device, against a real application. Identity proves which session is in use, endpoint telemetry shows what the device is doing, and application controls show what the destination will accept. Treating any one of those as the whole answer leaves a blind spot in the others.
The practical implication is that organisations should classify these controls by the decision they make, not by the technology they sit inside. Login-time checks can tell you who or what obtained access, but they do not answer whether the next browser action is safe, appropriate, or within the agent’s delegated authority. That is why execution-time governance matters as much as access-time authentication.
For readers who want the broader agent security model, Agentic AI Security Guide frames the layered threat model, while Zero Trust for AI Agents shows why policy must be enforced per action rather than assumed from prior login success.
Where action governance belongs in the stack
Action governance is the layer that decides whether the agent may proceed with a specific browser step, even when identity has been established and the endpoint looks healthy. In practice, that means evaluating the requested action against task scope, current context, destination risk, and whether the action is still consistent with the original intent. It is not a replacement for identity or endpoint control, it is the control that binds them together at the moment of execution.
That placement matters because browser-based agents can move quickly through apparently ordinary flows: search, form submission, approval clicks, data transfer, or account changes. If governance lives only in an upstream login gate, the organisation learns the agent is authenticated, but not whether the agent should be allowed to continue when the page content, target, or requested transaction changes. Close-to-execution controls reduce that gap by evaluating the action before it is committed.
This is also where application security and delegated-authority controls meet. AI Agent Authorisation Guide is useful where the core question is whether the agent’s current action is within scope, and Browser and Computer-Use Agent Security Guide is the right reference when the concern is browser session use, site scope, and confirmation at the point of action.
How to separate identity, endpoint, application and governance responsibilities
A useful operating model is to assign each layer a distinct question. Identity answers, “who or what is the actor?” Endpoint answers, “is the device or runtime trustworthy enough to proceed?” Application security answers, “is the target site or API behaving as expected?” Action governance answers, “should this specific action happen now?” If those questions are collapsed into one control, teams tend to overtrust the login event and underinvest in the decision point that actually matters.
That separation also helps when incidents are investigated. Identity evidence shows the session origin and authentication path. Endpoint evidence shows local process, browser, and device behaviour. Application logs show target interactions and rejection points. Governance evidence should show why the action was approved or blocked, by which policy, and under what context. Without all four, it is hard to tell whether a bad outcome came from stolen access, a compromised device, a permissive application flow, or a missing approval rule.
For teams building the control set, AI Agent Observability, Audit and Incident Response Guide supports the logging and attribution layer, while Agentic AI Identity Guide helps when the deeper question is how the agent is represented, delegated, authenticated, and retired across the session lifecycle.
Risk and Threat Considerations
Browser-driven agents are attractive to attackers because they operate through legitimate sessions, human-looking flows, and trusted destinations. If organisations treat the login event as sufficient control, a compromised agent session can be used to submit transactions, exfiltrate data, or approve actions that appear ordinary at the browser level. The risk grows when the agent has broad session reach, reusable credentials, or no per-action challenge.
Failure mechanism: The control fails when trust is granted at authentication time, but the later browser action is never re-evaluated against scope, destination, or intent. In that case, a valid session can still be used for unsafe or unintended actions, especially when the endpoint and application each see only part of the story.
Impact: Organisations can get credentialed, policy-compliant access that still produces unauthorized business actions, data exposure, or transaction abuse. The result is often delayed detection, because every individual layer may look normal while the combined decision is unsafe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Browser agents can overstep delegated authority or misuse session access. |
| Recommendation — Enforce per-action authorization for agent browser steps and limit delegated privilege. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent browser controls often fail when sessions or tokens are broader than needed. |
| Recommendation — Reduce session and token scope so browser agents cannot act beyond intended bounds. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Browser control decisions depend on how session credentials are issued and managed. |
| AC-6 — Least Privilege | Agentic browser use should be constrained to the minimum authority needed. | |
| Recommendation — Control credential lifecycle so browser sessions cannot outlive their intended authority. Limit each agent session to the smallest set of browser actions and resources needed. | ||
| OWASP ASVS | V8 — Authorization | Browser actions require authorization checks beyond initial login state. |
| Recommendation — Verify every sensitive browser action against authorization rules before execution. | ||
Practitioner Guidance
What to prioritise: Put policy at the point of action for anything that can modify data, move money, approve workflows, or expose sensitive content. If the action is reversible and low impact, light-touch enforcement may be enough; if it can create downstream business or security harm, require explicit step-up or human confirmation.
What to verify: Make sure you can prove three things for a blocked or approved action, the authenticated principal, the device or browser state, and the policy reason for the final decision. If you cannot reconstruct that chain, the control is too thin to trust.
Practitioner takeaway: The right model is not “identity or endpoint or application,” it is a stacked decision path where action governance is the final gate that stops a legitimate session from becoming an unsafe act.
Related resources from NHI Mgmt Group
- Should organisations treat identity controls as part of application security?
- When should organisations prioritise browser security over other identity controls?
- Should organisations rebalance investment from identity controls to application security?
- Should organisations treat AI data security as a replacement for broader cloud and endpoint controls?