Why User Permission Is Not AI Agent Permission: Google Drive, Confluence, and Delegated OAuth Access

An employee asks a coding agent to summarize a confidential contract in Google Drive. The employee can open the file. Their agent holds a delegated OAuth token that carries the employee's access. Technically, nothing stops the agent from reading it.

Should it?

Most teams answer "yes, it's their file" and move on. That answer treats two different questions as one. Source-system permission tells you whether the person may see the document. It does not tell you what an autonomous process acting for that person may do with it.

What a read permission actually decides

When Google Drive, Confluence, or SharePoint says "Alice can view this file," it has decided one thing: Alice, in an interactive session, may be shown this content. It has not decided any of the following:

Question	Answered by Alice's file permission?
May Alice read the file?	Yes
May a process acting for Alice copy it into a sandbox filesystem?	No
May that process send it to a model endpoint? Which one?	No
May it persist after the task ends?	No
May it be written into another workspace, ticket, or pull request?	No
Is this task a reason Alice would approve of?	No

A human who reads a confidential document applies judgment, employment terms, and social context without being asked. An agent applies whatever its runtime and prompt allow. The permission that was designed for the first case is being reused for the second.

Why delegated OAuth makes this easy to miss

Agents usually reach data through delegated authorization: the user signs in, grants an application a set of scopes, and the application acts on their behalf. That model is sound for apps. Scopes narrow what the application may request, and the identity provider records who consented.

But scopes are coarse by design. A scope such as read access to a user's files says nothing about whether an individual file is labeled Confidential, or whether the runtime receiving it can block egress. The token proves who delegated. It does not encode how this particular object may be handled by an agent.

If you want to see what your identity provider actually advertises about scopes, grant types and signing algorithms, the OIDC Inspector reads a provider's discovery document and shows it in one place. That is the identity half of the picture. The data-handling half has to come from somewhere else.

Three things that change when the reader is an agent

1. Retention is not implied

An interactive session ends when the tab closes. An agent can write the content to a scratch directory, a vector store, a log, or a memory file. Whether that is acceptable depends on a rule your organization has to state: "Confidential data may be used by agents only in non-persistent sessions."

2. Transmission is part of the workflow

To summarize a document, the agent usually sends it to a model. Which model, hosted where, under which retention terms, is a data-handling decision. The source system has no opinion about it.

3. Task context matters

"Summarize this contract" and "paste this contract into a public issue tracker" use the same read permission. Only one of them is plausibly what the employee intended. Agent policy needs a way to scope access to a task, not just to a person.

The model: three inputs, one intersection

A workable way to think about it:

effective agent access =
    source entitlement          (what the user may open, right now)
  ∩ enterprise agent policy     (what agents may do with this class of data)
  ∩ runtime capability          (what the target environment can actually enforce)

Each term can only reduce access. If the user lacks entitlement, nothing flows. If policy says Confidential data needs an isolated, non-persistent session and the runtime cannot provide one, the agent should receive a safer representation or nothing, and the decision should say why.

The third term is the one teams skip. A policy that nobody can enforce is documentation. The runtime has to demonstrate the control, or the decision fails closed.

What to do this week

You do not need a new product to start closing this gap. Four steps:

1. Pick one classified source and one agent task. For example, Confidential files in Google Drive and a "summarize" task.
2. Write the agent rule in one sentence per classification. "Confidential: isolated session, read-only input, approved model endpoint only, no persistence."
3. Inventory what each runtime can enforce. Local coding agent, cloud sandbox, Kubernetes job: they differ, and the difference is the finding.
4. Decide the fallback. When a runtime cannot meet the rule, do you deny, or release metadata or a transformed view?

Write the decision down in a form a security reviewer can read later: the facts, the rule version, the controls applied, and the outcome. "The agent had Alice's token" is not an explanation.

Where ContextIQ fits

ContextIQ Agent Data Policy is an Enterprise Preview built around exactly this translation: resolve the object's classification and the user's current entitlement, apply the organization's agent rule, check what the target runtime can enforce, and return a decision with evidence. The initial validation path is Google Drive to NVIDIA OpenShell; Confluence and other runtimes are planned, not supported today.

It is not generally available. We are working with design partners who have a classification scheme in place and one concrete agent workload to test. If that describes you, request an Enterprise Preview demo.