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

Sesetengah pasukan berpendapat bahawa semakan bagi setiap tindakan menambah kependaman dan kerumitan kod, terutamanya apabila pembantu AI perlu memanggil banyak alatan secara berturutan dengan pantas. Mereka menyatakan bahawa satu token sesi dapat mengelakkan beban tambahan untuk mengambil dan mengesahkan token baharu bagi setiap panggilan. Walau bagaimanapun, pertukaran yang berlaku adalah pendedahan yang jauh lebih tinggi terhadap penyalahgunaan. Perkhidmatan pengesahan token moden direka untuk beroperasi dalam mikrosaat, dan perjalanan balik rangkaian tambahan boleh dikumpulkan atau disimpan dalam cache tanpa mengorbankan prinsip keistimewaan paling rendah. Dalam persekitaran di mana integriti data dan pematuhan adalah perkara yang tidak boleh dirunding, kos prestasi yang kecil adalah tidak sebanding dengan pengurangan risiko yang diperoleh.

Perkara yang perlu diperhatikan seterusnya

  • Penggunaan token berskop dalam SDK AI – Perhatikan kemas kini pada kit alatan platform AI utama; banyak yang mula menyediakan fungsi pembantu untuk skop berasaskan OAuth.
  • Rangka kerja polisi-sebagai-kod – Penyelesaian yang sedang muncul membolehkan pasukan mengisytiharkan peraturan kebenaran dalam fail deklaratif, dan menguatkuasakannya secara automatik semasa masa larian.
  • Log audit yang memaparkan keputusan bagi setiap tindakan – Memandangkan lebih banyak platform merekodkan setiap semakan kebenaran, organisasi akan mendapat keterlihatan tentang tindakan AI mana yang dibenarkan atau disekat, yang seterusnya membantu penambahbaikan polisi pada masa hadapan.

Rumusan

Menganggap sesi yang telah log masuk sebagai kebenaran untuk melakukan apa sahaja adalah resipi kepada kesan yang tidak diingini. Dengan memindahkan keputusan kebenaran daripada saat log masuk kepada setiap panggilan alatan individu—dan dengan memanfaatkan token berskop yang berjangka pendek—aplikasi AI dapat mengekalkan kemudahan ejen autonomi sambil melindungi data, mematuhi peraturan, dan mengelakkan kemalangan yang merugikan. Baris kod tambahan adalah harga yang kecil untuk sistem yang mengajukan soalan yang betul setiap kali sesuatu tindakan cuba dilakukan.