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

Certaines équipes soutiennent que les vérifications par action ajoutent de la latence et de la complexité au code, surtout lorsque l'assistant IA doit appeler de nombreux outils à la suite. Elles soulignent qu'un jeton de session unique évite la surcharge liée à la récupération et à la validation d'un nouveau jeton pour chaque appel. Le compromis, cependant, est une exposition nettement plus élevée aux usages abusifs. Les services modernes de validation de jetons sont conçus pour fonctionner en quelques microsecondes, et l'aller-retour réseau supplémentaire peut être regroupé ou mis en cache sans sacrifier le principe du moindre privilège. Dans les environnements où l'intégrité des données et la conformité sont non négociables, le coût de performance modeste est largement compensé par la réduction des risques.

À surveiller ensuite

  • Adoption de jetons à portée limitée (scoped tokens) dans les SDK d'IA – Surveillez les mises à jour des principaux kits d'outils des plateformes d'IA ; beaucoup commencent à proposer des fonctions utilitaires pour les portées basées sur OAuth.
  • Frameworks de type « Policy-as-code » – Des solutions émergentes permettent aux équipes de déclarer des règles d'autorisation dans un fichier déclaratif, en les appliquant automatiquement lors de l'exécution.
  • Journaux d'audit mettant en évidence les décisions par action – À mesure que davantage de plateformes enregistrent chaque vérification d'autorisation, les organisations gagneront en visibilité sur les actions d'IA autorisées ou bloquées, ce qui permettra d'ajuster les politiques futures.

À retenir

Considérer une session connectée comme une permission de tout faire est une recette pour des conséquences imprévues. En déplaçant la décision d'autorisation du moment de la connexion à chaque appel d'outil individuel — et en exploitant des jetons à portée limitée et de courte durée — les applications d'IA peuvent conserver la commodité des agents autonomes tout en protégeant les données, en respectant les réglementations et en évitant des incidents coûteux. Les lignes de code supplémentaires sont un prix dérisoire pour un système qui pose la bonne question à chaque tentative d'action.