The Permission–Data Collision: Why Better-Connected Agents Create New Exposure

Part 4 of the AI Agents in the Real World series.

A calendar assistant needs the calendar.

Then it needs email to find the meeting request, contacts to identify the attendees, a cloud drive to retrieve the agenda, messaging to notify the team, and a browser to book a room.

Each connection looks reasonable on its own. Together they create a system that can read private messages, infer relationships, retrieve documents, and send information outside the boundary where it was found.

The permission problem with AI agents is not simply that they receive too much access.

It is that agents compose access while interpreting untrusted content.

That collision changes an old identity-and-access-management problem into an active decision path.

Permission answers “can,” not “why”

A user may be allowed to read a salary spreadsheet. The same user may be allowed to post in a team channel. Those facts do not imply that an agent acting for the user should copy salary data into the channel.

Traditional access control usually evaluates a request such as:

Can identity X perform action Y on resource Z?

An agentic system also needs to evaluate:

Is this action still necessary for the delegated purpose, given where the data came from, what the plan has become, and where the result will go?

The first question is resource authorization. The second is purpose and information-flow control.

Without both, every individual call can be authorized while the overall run is not.

The connected-agent failure path

Consider a hypothetical but technically ordinary sequence:

1. A user asks an agent to summarize unread email and prepare follow-ups.
2. One email contains hidden or visible instructions addressed to the agent.
3. The agent treats those instructions as part of its task.
4. It searches a connected drive for a named document.
5. It sends a “follow-up” containing material from the document to an external address.

No single capability is exotic. The failure requires four ordinary conditions:

• external content can influence planning,
• the agent carries the user’s broad read access,
• a send tool is available in the same run,
• no policy tracks information from source to destination.

NIST describes indirect prompt injection as agent hijacking: malicious instructions in data ingested by an agent can cause unintended actions. OpenAI’s prompt-injection guidance similarly advises users to narrow instructions and access, and to inspect consequential confirmations. These sources differ in product and scope, but agree on the boundary: content encountered during work must not silently acquire the authority of the user.

Why the user’s token is the wrong abstraction

The fastest prototype authenticates the agent as the user.

That shortcut creates three problems:

1. Attribution: downstream systems cannot reliably distinguish a person’s action from an agent acting for that person.
2. Scope: the agent inherits years of accumulated access unrelated to the current task.
3. Revocation: stopping one run may require revoking a credential needed for all of the user’s work.

NIST’s August 2026 identity guidance calls credential sharing between humans and agents a common but unsafe pattern. It recommends treating agents as first-class entities with their own identifiers, credentials, and entitlements bound to the user or system operating them. It also warns about static API keys and long-lived bearer tokens carried across tools and networks.

This does not mean the agent acts independently of the user. It means the identity record should preserve both parts:

agent identity + human/organizational principal + delegated purpose

“On behalf of” is part of the security event, not an excuse to erase the agent from it.

Existing permissions become more dangerous when retrieval improves

Enterprise knowledge systems often contain accidental access: old group memberships, broad sharing links, broken inheritance, ownerless sites, and documents that were technically available but practically undiscoverable.

Search and agents remove the friction that kept this oversharing latent.

Microsoft’s own SharePoint guidance tells administrators to identify high-risk sites with broad audiences, excessive permissions, broken inheritance, sensitive content, and governance gaps. It provides restricted content discovery, access control, data-loss prevention, and agent management to reduce accidental exposure in Copilot and agentic experiences.

This is a useful reality check: “the agent respects existing permissions” is necessary, not sufficient. If the permissions are wrong, the agent can make the wrongness cheap to exploit and hard to notice.

The action authorization envelope

Every side-effecting tool call should arrive with a purpose-bound envelope that a deterministic policy layer can evaluate.

run_id: run_0194
agent_id: support_agent
principal_id: user_1842
delegation_id: del_20260901_0042
 
intent: support.refund.prepare
action:
  tool: messaging.create_draft
  destination: customer_4821
  external_effect: false
 
data_inputs:
  - source: orders.read_view
    classifications: ["customer_data", "transaction_data"]
  - source: refund_policy.current
    classifications: ["internal_policy"]
 
prohibited_flows:
  - from: "internal_policy"
    to: "external_message"
    transform: "verbatim_copy"
 
capability:
  audience: messaging_gateway
  expires_at: "2026-09-01T10:00:00+05:30"
  maximum_uses: 1
 
approval:
  required_before: messaging.send
  approved_proposal_hash: null

This is an illustrative contract. The exact authorization technology can vary. The important properties are:

• the agent is identifiable,
• the principal is preserved,
• the task purpose is explicit,
• the target and effect are typed,
• input data carries classification and provenance,
• the capability is narrow and short-lived,
• send or mutation authority is separate from draft authority.

Seven controls that close the path

1. Distinct agent identity

Issue the agent its own workload identity. Bind it to the human or service principal and the exact delegation. Downstream logs should answer who requested, which agent acted, and under which policy.

2. Just-in-time capability

Do not place all possible tool tokens in the agent’s environment. Mint a capability after the plan reaches an authorized step. Scope it to audience, action, resource, amount or field set, and expiry. Prefer proof-of-possession or sender-constrained credentials where the platform supports them.

3. Purpose-specific data views

Expose the smallest useful representation:

• calendar free/busy instead of event bodies,
• customer eligibility facts instead of the whole CRM record,
• repository diff and relevant files instead of the developer’s home directory,
• document snippets with source identifiers instead of bulk export.

Data minimization improves security and often improves model focus.

4. Treat retrieved content as evidence, never authority

Emails, pages, documents, tool descriptions, and tool results can inform the task. They cannot grant a new permission or redefine the governing goal.

This boundary must exist outside the prompt. The tool gateway should reject an unauthorized call even if the model produces a persuasive rationale.

5. Track source-to-destination flow

Label sensitive data when it enters the run and enforce policy when it leaves. At minimum, record source system, classification, tenant, subject, and permitted destinations.

Perfect semantic taint tracking is hard. Useful controls do not require perfection. Blocking secrets from external messages, employee data from customer tools, and one tenant’s evidence from another tenant eliminates high-severity paths.

6. Freeze consequential proposals

Before send, publish, purchase, delete, or mutation, compile the exact proposal. Approval should bind to recipient, fields, amount, and content hash. If the agent edits the proposal or changes the destination, approval expires.

The delegation contract explains why the confirmation should show a material diff rather than “Continue?”

7. Re-evaluate on plan change

Authorization at the first step does not cover every future plan. Re-evaluate when the agent changes tool, data class, destination, subagent, effect type, or environment.

This is continuous authorization in the practical sense: not a model debating policy at every token, but deterministic checks at meaningful transitions.

An individual can reduce the same risk

Consumer agents often expose fewer enterprise controls, but users can still narrow the path.

• Use logged-out browsing when the task does not require an account.
• Connect one service for one task instead of every account permanently.
• Prefer read-only and draft modes.
• Use a separate browser profile or low-privilege account for agent activity.
• Never enter passwords, recovery codes, seed phrases, or one-time codes into agent chat or tool-elicitation fields.
• Review the exact data being sent, not only the name of the destination app.
• Revoke sessions and integrations after a sensitive task.
• Avoid broad instructions such as “read everything and handle whatever is needed.”

These steps do not make prompt injection disappear. They reduce what a successful hijack can reach.

The enterprise rollout order

Before connecting a new agent to production data and actions:

1. Inventory the identities, tools, data sources, destinations, and subagents.
2. Draw the possible paths between them, including read-to-send paths.
3. Repair standing permission and oversharing problems in the source systems.
4. Create purpose-specific views and tool methods.
5. Separate read, draft, and commit capabilities.
6. Add short-lived authorization and exact action receipts.
7. Test direct and indirect injection, cross-tenant access, data exfiltration, stale tokens, and revocation.
8. Roll out one workflow and one authority tier at a time.

The AI Agent Access Graph provides the CISO-level inventory and path model. The agent security threat model expands the source-to-sink testing program.

What to measure

Track more than blocked calls.

Connection is not control

The industry is making agents easier to connect. That is useful infrastructure. It also removes the friction that once limited how quickly identity, data, and action could combine.

The safe design is not a disconnected agent. It is a connected agent whose purpose, identity, evidence, capability, and destination remain bound together at every consequential step.

If the system can answer “yes, this user can access both,” but cannot answer “why is this agent moving information between them now?”, the authorization model is incomplete.

What to read next

• Agent Memory Needs a Right to Correct and Forget
• The AI Agent Access Graph
• Prompt Injection Is a Boundary Problem
• Identity Layer