Agentic security in the enterpriseAdvancedLesson 1486 min read

Delegated access: acting on behalf of users

When an agent works for a person, it should carry that person's permissions, narrowed further, never widened. OAuth scopes, consent and audit make that real.

✦ Ask the tutor 🧪 Lab · 30 min 📝 Lesson test

Speed

Lesson in motion

In 60 seconds

Delegated access: acting on behalf of users

When an agent works for a person, it should carry that person's permissions, narrowed further, never widened. OAuth scopes, consent and audit make that real.

1/4

In simple words

If you send your younger brother to the bank with a signed note, the note should say exactly what he may do: "collect my passbook". Not "do anything with my account". And the bank should write down that he came because of your note.

Many agents act on behalf of a user: an assistant reads your mail, a scheduling agent books your meetings, a support agent looks up your orders. The agent now needs two things answered on every action: which agent is acting, and for which human.

OAuth 2.0 is the widely used standard for this kind of delegation. The user approves a request; the agent gets an access token limited by scopes (what it may do) and a lifetime (how long). The user's password never goes to the agent.

Two ways an agent can hold rights

Model	How it works	Good for	Main risk
Agent's own rights	The agent has its own identity and permissions, the same for every user	Background jobs with no user, such as nightly reports	Confused deputy: any user can ask it to use rights they do not have
On behalf of the user	The agent gets a token tied to the specific user, with narrowed scopes	Assistants that read or act on a user's data	Scopes set too wide; tokens living too long

The golden rule: an agent acting for a user must never be able to do more than that user could. Ideally it can do much less: only the part of the user's access this task needs.

Effective access (the idea)text

effective access = user's permissions
                 ∩ scopes granted to this agent
                 ∩ what this task needs right now

Example: Meera can read and send mail and read all shared drives.
The agent was granted: mail.read, calendar.read
This task ("summarise today's mail") needs: mail.read (today only)
=> The agent may read today's mail. It cannot send, and cannot open drives.

Designing scopes

Scopes that are too wide

"full_access" to the mailbox
Read and write asked for together, "just in case"
Refresh tokens that last for months with no review
One consent screen that covers every feature forever

Scopes that fit

Separate read and write scopes; ask for write only when a write feature is used
Resource limits where the platform supports them (one folder, one project)
Short access tokens; refresh limited and revocable
Step-up consent: ask again when the agent wants a new, riskier power

Chains of delegation

Sometimes an agent calls another service that must also know who the user is. Passing the user's original token along everywhere is risky: every service that sees it can reuse it. A safer pattern is token exchange (OAuth 2.0 Token Exchange, RFC 8693, is one standard way): the agent swaps its token for a new one that is meant for the next service only, with narrower scopes. Some identity platforms call this an "on-behalf-of" flow.

Consent people can understand

Say what the agent will do in plain words: "Read your calendar to suggest meeting times. It cannot delete events."
Ask for the smallest scopes first; ask for more when a feature needs it.
Let users see and remove what they granted, in one place.
For company data, admins may need to approve which apps users can grant access to. Otherwise, anyone can hand company mail to any app.

Audit: who authorised what

Every log line for a delegated action should show the agent identity, the human it acted for, the scopes used, and the consent or approval behind it. Your runtime attaches these, not the model. If the model can type the user ID into a tool argument, the model can type someone else's.

Watch out

A token issued to an agent is still a bearer credential: whoever holds it can use it. Keep tokens out of the model's context and out of logs, and prefer short lifetimes.

Try this. Open your account's list of connected apps (mail, calendar or code hosting). For one AI app, check what it can do. Is it read-only? Does it need everything it has?

Watch and read more

OAuth 2.0oauth.net · reading

Lab

A scope design and a plain-language consent screen for a meeting assistant agent.

~30 min

The problem

Design delegated access for a meeting assistant that (a) reads a user's calendar, (b) suggests meeting times, (c) books meetings after the user confirms, and (d) writes a summary into a shared notes folder.

List the scopes you would request, split into read and write. Mark which ones are asked for at first sign-in and which only when a feature is first used (step-up).
Write the consent text a user will see, in plain language, under 80 words.
Write the effective-access rule for "book a meeting" as user permissions ∩ agent scopes ∩ task need.
Write the fields that each audit log line must contain.
Say what an admin must approve before any employee can grant this agent access.

You are done when

Read and write scopes are separated, and write is requested only when needed
The consent text says what the agent can and cannot do, in plain words
The effective-access rule never gives the agent more than the user
Audit fields include agent identity, the human, scopes used and the approval

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1The notes folder is shared with the whole department. The agent writes summaries there on the user's behalf. What new risk appears?Reveal

The agent can move data from a private place (the user's calendar and meetings) to a wider audience (the whole department). Even if every permission is correct, the summary may include private details. Limit what goes into summaries, let the user review before posting, or write to a folder only the attendees can see.

Q2A user revokes the agent's access, but the agent still has a valid access token for a few minutes. How do you handle that gap?Reveal

Keep access tokens short-lived so the gap is small, make sure refresh tokens are revoked at once, and, for high-risk actions, have the resource check revocation or session status in real time rather than trusting the token alone. Also stop any running tasks for that user when access is revoked.

Please sign in to continue.

Questions people ask

Why not just give the agent the user's password?

Because then the agent has everything the user has, forever, and nobody can tell the agent's actions from the user's. OAuth gives a limited, revocable token instead, and the password stays with the user.

What if the agent needs access the user does not have?

Then it is not really acting on behalf of the user; it is acting with its own rights. That is sometimes fine (for example a system check) but must be designed carefully: the agent must check what the user is allowed to see before returning anything, or you have built a confused deputy.

How long should tokens live?

As short as is practical for the task. Access tokens are commonly short-lived, and refresh tokens should be limited, revocable and reviewed. There is no single right number; the more a token can do, the shorter it should live.

Can users give an agent access to company data on their own?

On many platforms, yes, unless admins restrict it. Most enterprise identity platforms let admins require approval before users grant third-party apps access to company data. Turning that on is a key control against shadow agents.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.