i³ Threat Advisory:
AI Agent Access Control: When Permissions Exceed Entitlements

Executive summary (TL;DR)

• This advisory examines how misconfigured AI agent permissions can expose restricted enterprise data.
• This matters now because shared agents are being deployed faster than access controls are adapting.
• Risk is highest for organizations allowing employees to build and broadly share agents.
• In this investigation, a user accessed Salesforce data without native permission.
• Primary risks include unauthorized disclosure, IP exposure, and insider trading.
• Organizations should prioritize entitlement-parity reviews and identity and cloud-audit integrations.

Threat overview

Your organization has moved quickly to use AI to augment its workforce. The security team has restricted agentic AI to corporate Microsoft Copilot and authorized cloud providers. Teams have connected these services to agents that aggregate information to accelerate projections and documentation.

A high-performing IT employee implements the agents and responds to requests for additional functionality. Unknown to the organization, the employee is an undiscovered DPRK operative who has evaded detection. The operative colludes with a newly contracted hire and advises them on using a Microsoft Copilot agent to aggregate sensitive financial data.

This scenario exposes a growing AI agent security risk: a user may be unable to access a system directly but still retrieve its data through an agent whose permissions exceed their own.

The video below demonstrates a user who cannot sign in to Salesforce but can access Salesforce data through a misconfigured Microsoft Copilot agent.

Enterprise AI often accesses email, SharePoint and cloud storage, code repositories and knowledge databases. What happens when an agent’s permissions exceed those of the querying user?

We first described this risk in iTA-26-01, where agentic AI browsers connect to cloud services and a threat actor can exploit native tools to accelerate an attack. The same risk applies when a legitimate account receives more information than its user should access.

In this iTA we summarize research from our integration-connectors work. We present one use case referenced above and will publish additional use cases later covering integrations, DI releases and newer DAS versions.

How correctly configured AI agent access controls work

In a correctly configured environment, the user submits a query targeting company resources. The agent forwards the request to the system of record’s authorization layer, applying the same access check used when the user opens a file directly.

The system returns only the resources the user is permitted to access. The agent searches and transforms that authorized data before returning its response.

How misconfigured AI agent permissions create risk

A misconfiguration can grant the agent higher privileges than the querying user. The agent may then search documents outside the user’s authorized access, include restricted information in its output, and return that information without requiring the user to bypass an access control.

This creates a form of agent privilege escalation. The user gains effective access through the agent even though their native identity remains blocked from the underlying system or repository.

No file transfer is required. Depending on the environment, no existing policy event may be triggered.

DTEX investigation and indicators

The DTEX Forwarder captures what a user did on an endpoint. Investigating AI agent access control risks also requires understanding what the user was authorized to do at that time.

That context rarely exists on the host itself. Access rights, group memberships, and account status are maintained in identity systems. Employment status, role changes, and departures are tracked in human resources information systems. Cloud audit logs may separately record what an AI assistant surfaced to a user.

Historically, analysts had to correlate endpoint activity with identity records, HR data, and SaaS audit logs after an incident occurred.

Integrations bring this context into the investigation workflow. When endpoint telemetry is combined with identity, HR, and enterprise-system data, DTEX can evaluate signals unavailable from endpoint activity alone. These signals can influence risk scores and detection outcomes, allowing investigations and detections that once depended on manual correlation to operate natively.

This gives analysts visibility into AI agent permissions and access conditions that would otherwise be difficult to identify.

Primary use case

The use case demonstrates how a misconfigured AI agent can grant access to data a user would not normally be able to reach.

The Activity_Type values and the presentation of these indicators are subject to change before product release.

Microsoft Copilot conversation indicators

• The Source_Integration variable helps investigators identify the origin of the data. As DTEX adds integrations, some sources may provide more useful investigative context than others.
• Unlike HTTP Inspection Filter rules, the chat prompt and chat response do not appear in the same activity document.
• To connect the prompt and response during an investigation, open the activity document and apply an include filter to Chat_Id.

Microsoft Copilot Invoke Agent indicators

• The source integration helps investigators connect human behavior with AI agent behavior.
• The activity record provides a brief, human-readable summary and identifies the agent invoked by the Copilot chat.
• The additional detail helps investigators understand the scope and limits of the tool call.

Inbound integrations for investigations and threat hunts

The first inbound integrations delivered through the Integration Framework each collect a cyber or identity signal that the DTEX Forwarder cannot see on the endpoint. DTEX normalizes these signals to OCSF and maps them into the activity timeline, where they can change a user’s risk score.

For this AI agent access control use case, the integrations provide both parts of the access-without-entitlement assessment:

• What the user was entitled to access, based on identity-provider data
• What the shared agent surfaced, based on cloud audit activity

These signals previously had to be connected manually.

How integrations support AIRM AI threat hunts

Analysts can use these signals to trace activity from a Microsoft Entra entitlement baseline through Microsoft Defender for Cloud Apps audit records. This allows them to determine whether an AI agent returned information that the user could not have accessed under their own permissions.

Today, this process is investigative. The longer-term objective is to embed the same enrichment into native indicators so that entitlement inheritance can be identified automatically within AIRM.

Instead of requiring analysts to manually connect identity, entitlement, and audit data after an alert, AIRM will be able to evaluate these relationships during detection. By combining audit activity with user identity and entitlement data, AIRM can establish who initiated a query, assess whether the information returned aligns with the user’s authorized access, and detect cases where AI-assisted access exceeds normal permissions.

This makes entitlement drift a detectable AI agent security condition rather than an issue found only through manual investigation.

Lethal trifecta assessment

The lethal trifecta is used to assess an AI agent’s capability and the resulting exposure. The following table summarizes the access demonstrated during the use case.

Insider threat profile

The organization allows teams to build and share their own Copilot Studio and retrieval-augmented generation agents to support everyday work.

Policy treats access to an agent as equivalent to access to a productivity tool. No technical control enforces entitlement parity between the agent’s embedded knowledge base and the people with whom the agent is shared.

An engineering team builds an agent over a restricted project repository to answer questions about its work. To reduce repetitive requests for updates, the team shares the agent broadly with delivery, support, and contractor groups.

A junior contractor is given access to the agent but has no native permission to the underlying repository. The contractor asks a routine question. Because the agent operates using its build-time access rather than the contractor’s permissions, the response includes restricted content.

No file is transferred, and no policy is triggered.

From a risk perspective, responsibility ultimately falls on the person who built and overshared the agent. The exposure was also enabled by several control gaps aligning under the Swiss cheese model of risk. There was no entitlement-parity review, sharing was overly broad, and the agent’s corpus was embedded under static permissions.

Together, these gaps allowed a benign query to bypass access controls the contractor could not have passed directly.

Shared agent access inheritance profile

The population represented by this profile is likely to grow with organizational scale and the adoption of self-service agent building.

Application usage: The builder grounds the agent on a restricted knowledge base under a build-time service identity. The agent is shared broadly without an entitlement-parity review. Downstream users query the agent, which returns content using the agent’s permissions rather than their own.

Insider threat persona

The over-privileged user

DTEX selected the over-privileged user as the primary persona because shared agents can give a person access to data far beyond their native permissions without requiring technical skill or deliberate circumvention.

A single query to an over-scoped agent may be enough. Unlike insider threat personas that must bypass a control, this user inherits access simply by being granted access to the agent. The risk lies partly in how little visible activity the access generates.

This persona distinguishes the person who benefits from inherited access from the person who created the exposure. That distinction helps security teams detect and respond before waiting for a policy violation that may never occur.

• Motivation: Convenience or curiosity while completing a routine task, with no intent to access restricted data.
• Behavioral indicators: Querying a shared agent for content beyond the user’s job scope and receiving results without corresponding native file access, transfer activity, or a policy event.
• Risks: Misuse of data, accidental exposure of restricted intellectual property, and insider trading based on information the user was never entitled to see.

Mitigations: what organizations should do now

DTEX improvements

Detecting AI agent access control failures requires endpoint behavior to be enriched with identity and access context from outside the host.

The DTEX Forwarder records user activity, but it cannot independently determine what the user was entitled to do. Entitlements, group membership, and records showing what a shared agent surfaced reside in other systems. Bringing these records together can turn access inheritance from a manual, after-the-fact investigation into an automated detection.

Organizations should take the following actions:

• Update to the latest DAS and DI releases. The correlation rule and Agent Privilege Escalation AI factor supporting this use case ship in the DTEX Intel package. Keeping DAS and DI current provides coverage for this use case and future agent behaviors as the detection library expands.
• Enable Integration Framework connectors. Connecting an identity provider or directory, such as Microsoft Entra ID or Okta, supplies the user’s native entitlement baseline. Microsoft Defender for Cloud Apps supplies the record of what the agent surfaced. Both are required to identify inherited access because neither signal is available from the Forwarder alone.
• Add supporting context where available. HRIS and directory data can apply persona weighting to a detection. This allows the platform to prioritize activity involving a junior contractor, departing employee, or other higher-risk identity rather than treating every event equally.

Each connector adds cyber and identity signals that previously required manual correlation, when they were correlated at all. Enriching endpoint behavior with this context allows DTEX to identify insider risk scenarios that endpoint telemetry alone cannot reveal, without increasing the manual workload placed on analysts.

AI behavioral monitoring

Detecting inherited access requires more than checking entitlements at a single point in time. Security teams also need visibility into how an agent was configured, who can use it, and what it exposes over time.

This extends behavioral monitoring into the shared and embedded agent domain, where risk arises from the relationship between the user, the agent, and the data available to it.

Organizations should consider the following questions:

• Can we account for what the agent surfaced? Monitor the resources returned by the agent rather than relying on the prompt alone. This can reveal when restricted content reaches an unauthorized user without requiring prompt text to be ingested.
• Can we attribute access to the correct identity? Tie each query to the person who submitted it and assess the output against that person’s native permissions, rather than the agent’s build-time service identity. Without reliable attribution, inherited access can look identical to legitimate use.
• Can we see how the agent was built and shared? Configuration activity matters alongside query activity. Grounding an agent on a restricted knowledge base and sharing it broadly creates continuing exposure. These changes need to be visible and reviewable.
• Can we distinguish entitlement parity from entitlement drift? Monitoring should separate a user querying data they could already access from a user receiving data outside their permissions. This allows analysts to focus on meaningful AI agent access control mismatches.

Treating a shared agent as a distinct data pathway can surface cases where access exceeds entitlement before the exposure becomes a reportable data-loss event.