Authentication checks who you are; authorization decides what you may do. A growing number of AI-powered applications verify a user’s identity once at login and then let the underlying agent act on any resource for the rest of the session, effectively handing it a “blank check.” That design opens the door to accidental data leaks, unwanted emails, or even destructive database updates, and the risk grows every time an AI assistant can invoke multiple tools with millisecond latency.

Why the mistake keeps happening

Most AI developers treat the login screen as the sole security gate. The code asks for a password or a token, marks the session as “authenticated,” and then assumes that any subsequent request is safe. In a traditional web app a human user’s slow clicks provide a natural throttling point; a human will pause before hitting “delete.” An AI agent, however, can fire off dozens of tool calls in seconds. If the platform only asks “Is the user logged in?” each call inherits the same unrestricted privilege.

The root cause is convenience. Teams often provision a single long-lived service account for the whole application so that the code does not have to manage multiple tokens or scopes. That account typically has broad permissions—read, write, delete—across all projects. When an AI assistant runs inside that session it automatically inherits those rights, regardless of whether the current task actually requires them.

What’s at stake

  • Data exposure – An agent that can read any file after a user logs in may inadvertently pull confidential documents into a response that is later shared outside the organization.
  • Unintended actions – A support engineer’s AI helper could execute a raw SQL query against production databases simply because the engineer’s session is still active, even if the query is unrelated to the ticket being handled.
  • Regulatory compliance – Many data-protection rules require that access be limited to the minimum necessary. A blanket permission model can violate those principles and trigger audits or fines.
  • Operational cost – Mistakes that delete or modify records force teams to roll back changes, investigate root causes, and rebuild trust with users—all of which waste time and money.

The missing step: per-action authorization

Authorization should be evaluated at every “door” inside the system, not just at the front entrance. The question changes from “Who is this?” to “May this specific action on this specific resource happen right now?” Implementing that check does not require a complete redesign; it only needs a shift from a single session flag to short-lived, scoped tokens.

How it works in practice

  1. Request a token with a defined scope – When the AI agent needs to call a tool, it first obtains a token that lists the exact permissions required (e.g., read:ticket, execute:sql_query).
  2. Validate the token for each call – Before the tool runs, the service checks that the token includes the needed scope and that the token has not expired.
  3. Match resource to scope – If the request targets a particular project or database, the token must explicitly grant access to that identifier.
  4. Reject or allow – If any check fails, the call is denied and the agent receives an error it can surface to the user.

The code difference is straightforward. A “bad” approach might look like:

if session.is_authenticated():
    tool.run(params)

A “good” approach expands the check:

token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
    tool.run(params)
else:
    raise PermissionError

The second pattern adds a few lines but forces the system to ask the right question for every operation.

Standards that make it easier

OAuth 2.0 scopes already provide a widely adopted way to limit what a token can do. By issuing short-lived access tokens that encode scopes such as project:1234:write or email:send, developers can rely on existing libraries to perform the verification step.

The newer Rich Authorization Requests (RFC 9396) extend this idea, allowing a client to request granular permissions at runtime instead of pre-defining a static list. That flexibility is useful when an AI workflow may need to add or drop capabilities on the fly based on user intent.

Counter-argument: simplicity versus security

Some teams argue that per-action checks add latency and code complexity, especially when the AI assistant must call many tools in rapid succession. They point out that a single session token avoids the overhead of fetching and validating a new token for each call. The trade-off, however, is a dramatically higher exposure to misuse. Modern token-validation services are designed to operate in microseconds, and the additional network round-trip can be batched or cached without sacrificing the principle of least privilege. In environments where data integrity and compliance are non-negotiable, the modest performance cost is outweighed by the reduction in risk.

What to watch for next

  • Adoption of scoped tokens in AI SDKs – Keep an eye on updates to the major AI platform toolkits; many are beginning to expose helper functions for OAuth-based scopes.
  • Policy-as-code frameworks – Emerging solutions let teams declare authorization rules in a declarative file, automatically enforcing them at runtime.
  • Audit logs that surface per-action decisions – As more platforms record each authorization check, organizations will gain visibility into which AI actions are being allowed or blocked, informing future policy tweaks.

Takeaway

Treating a logged-in session as permission to do anything is a recipe for unintended consequences. By moving the authorization decision from the moment of login to every individual tool call—and by leveraging short-lived, scoped tokens—AI applications can keep the convenience of autonomous agents while protecting data, complying with regulations, and avoiding costly mishaps. The extra lines of code are a small price for a system that asks the right question each time an action is attempted.