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

חלק מהצוותים טוענים כי בדיקות לכל פעולה מוסיפות שיהוי (latency) ומורכבות לקוד, במיוחד כאשר עוזר ה-AI חייב לבצע קריאות למגוון כלים ברצף מהיר. הם מציינים כי טוקן (token) סשן יחיד מונע את העומס הכרוך בשליפה ובאימות של טוקן חדש עבור כל קריאה. עם זאת, המחיר הוא חשיפה גבוהה משמעותית לשימוש לרעה. שירותי אימות טוקנים מודרניים מתוכננים לפעול במיקרו-שניות, ואת ה-round-trip הנוסף ברשת ניתן לאגד (batch) או לשמור במטמון (cache) מבלי להקריב את עיקרון ההרשאה המינימלית (principle of least privilege). בסביבות שבהן שלמות הנתונים (data integrity) וציות (compliance) הם תנאי חובה, עלות הביצועים הצנועה נמוכה יותר מהתועלת שבצמצום הסיכונים.

מה כדאי לעקוב אחריו בהמשך

  • אימוץ טוקנים בעלי הרשאות מוגדרות (scoped tokens) ב-AI SDKs – עקבו אחר עדכונים בערכות הכלים של פלטפורמות ה-AI המרכזיות; רבות מהן מתחילות לחשוף פונקציות עזר עבור scopes מבוססי OAuth.
  • מסגרות עבודה של Policy-as-code – פתרונות מתהווים מאפשרים לצוותים להצהיר על חוקי הרשאה בקובץ דקלרטיבי (declarative), ואכיפתם מתבצעת באופן אוטומטי בזמן ריצה (runtime).
  • יומני ביקורת (Audit logs) המציגים החלטות ברמת הפעולה – ככל שיותר פלטפורמות יתעדו כל בדיקת הרשאה, ארגונים יזכו לנראות לגבי אילו פעולות AI מאושרות או נחסמות, מה שיסייע בשיפור מדיניות בעתיד.

שורה תחתונה

התייחסות לסשן מחובר כאל הרשאה לבצע כל דבר היא מתכון לתוצאות בלתי צפויות. על ידי העברת החלטת ההרשאה מרגע ההתחברות לכל קריאה בודדת לכלי – ועל ידי שימוש בטוקנים בעלי הרשאות מוגדרות (scoped tokens) ובעלי תוקף קצר – אפליקציות AI יכולות לשמור על הנוחות של סוכנים אוטונומיים תוך הגנה על נתונים, עמידה ברגולציה ומניעת תקלות יקרות. שורות הקוד הנוספות הן מחיר קטן עבור מערכת ששואלת את השאלה הנכונה בכל פעם שמנסים לבצע פעולה.