They surface connected data through an interface that can inherit overly broad permissions or trigger retrieval that the user should not have been able to perform directly. The problem is not only access to the model, but the authorisation path behind what the model can retrieve and reveal.
How broad access becomes unintended data exposure
Copilots and agents do not need to “break” a system to leak data. If they are connected to mail, chat, documents, tickets, code or line-of-business apps, they can surface information the user could not practically assemble on their own. The exposure usually comes from inherited permissions, weak retrieval boundaries, or an interface that makes privileged search feel harmless.
That is why the relevant control question is not just “can the model see it?” but “what authorisation path lets it retrieve, aggregate, and reveal it?” A benign prompt can become a disclosure event when the agent is allowed to act with broader rights than the person asking.
Where the authorisation failure actually happens
The failure point is often upstream of the model itself. A copilot may call a connector, search index, API, or workflow on behalf of the user, then return a result set that spans more than the user should access directly. If the access check happens only once at login, or only on the model front end, the downstream retrieval layer can still expose restricted records.
This is especially dangerous when the system blends three things: delegated access, broad connectors, and summarisation. Each part may be acceptable in isolation, but together they create a path where the user’s visible action is simple while the effective data reach is much wider.
Good design keeps the retrieval boundary as tight as the underlying entitlement model. If the system can answer by querying a source, it must still respect per-resource and per-action authorisation, not assume the user’s general session is enough.
Why agents magnify the blast radius
Agents raise the risk because they can chain actions. Instead of only reading a document, they may search across systems, join records, open attachments, call tools, or trigger follow-on actions. That makes an over-permissioned agent more than a passive viewer, it becomes an execution path for data aggregation and disclosure.
A well-placed control can prevent this. AI Agent Authorisation Guide is useful here because it frames the core discipline as task-scoped access, per-action decisions, and delegated authority rather than broad standing permission. When those controls are missing, the agent can reveal data that was never intended for direct user retrieval.
For practitioners, the key distinction is between access to a chat interface and access to the underlying system of record. If the agent can query more than the user could manually reach, the interface becomes an amplification layer for confidentiality risk.
Risk and Threat Considerations
Broadly connected copilots and agents create exposure when a small prompt can reach a large permission set. The practical failure mode is confused-deputy behaviour, over-broad retrieval, or token misuse, where the tool chain fetches and discloses data outside the user’s intended scope.
Failure mechanism: The agent inherits standing permissions, follows a permissive connector, or reuses a powerful token to retrieve data across systems, then exposes it through summarisation, autocomplete, export, or downstream tool output.
Impact: Sensitive messages, records, files, secrets, or business data can be disclosed at scale, often without an obvious exploit trail, because the activity appears to originate from an approved interface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broad agent or copilot rights can expose data beyond intended user scope. |
| Recommendation — Reduce standing rights and scope agent access to the minimum needed for each action. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agents that inherit broad authority can retrieve or reveal data they should not. |
| Recommendation — Enforce per-action authorization and remove excessive agent privilege. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Restricts what the copilot or agent can read and reveal through connected systems. |
| Recommendation — Apply least privilege to every connector, token, and retrieval path. | ||
| OWASP ASVS | V8 — Authorization | The issue is unauthorized retrieval and disclosure through application flows. |
| Recommendation — Verify that every data-access flow rechecks authorization at the object and action level. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Operational access control limits which connected resources an agent may expose. |
| Recommendation — Review and revoke overbroad access paths for copilots and agents. | ||
Practitioner Guidance
What to verify: Test the retrieval path, not just the UI. Verify which sources the agent can query, whether results are filtered at object level, and whether the same user session would be allowed to perform each underlying read directly.
Decision rule: If an agent can combine multiple data sources or trigger privileged search, treat it as an access-control design problem first and an AI problem second. Restrict standing rights, require per-action checks, and isolate high-value sources behind separate policy boundaries.
Common mistake: Teams often audit the model prompt or output filters while leaving the connector and token model untouched. That misses the main issue, which is whether the authorisation chain behind retrieval is narrower than the interface presented to the user.
Practitioner takeaway: The safest copilot is not the one that “knows less”, it is the one whose retrieval rights are no broader than the user’s legitimate need for that specific action.
Related resources from NHI Mgmt Group
- How should security teams reduce AI permission debt before copilots and agents turn old access into exposure?
- What should security teams do when enterprise agents need broad data access?
- Why do AI agents and copilots increase data exposure risk in regulated environments?
- How should organisations prevent broad data exposure when access controls are weak or absent?