Why do read-only AI workflows still create identity risk?

Read-only workflows still create risk because the agent can surface privileged context, combine signals across systems, and spread sensitive findings into places that were not previously authorised to see them. The control issue is what the agent can reveal, not only what it can modify.

Why Read-Only Workflows Still Change the Identity Boundary

Read-only access does not make an AI workflow harmless when the workflow can query multiple systems, aggregate results, and present them in a new context. The identity risk shifts from direct modification to disclosure, because the agent can expose privileged data, infer relationships across systems, or reproduce sensitive findings for users who were never meant to see them. That turns a narrow lookup path into a broader trust boundary. NHI Management Group research notes that only 5.7% of organisations have full visibility into service accounts, which matters here because invisible machine identities are often the ones feeding these workflows.

When teams treat read-only as low risk, they often miss that the agent is acting as a transformation layer, not a passive viewer. It can assemble context that no single human or system user would have been authorised to reconstruct from separate sources, especially in environments with weak role design or broad data entitlements.

How Read-Only Agents Leak Privilege Through Context

In practice, a read-only agent can still create identity exposure through three common mechanics. First, it can combine low-risk queries into a high-risk answer, such as correlating tickets, logs, and directory data to reveal ownership, hierarchy, or access patterns. Second, it can pull sensitive fragments from approved systems and place them into chat, tickets, or reports where the audience is broader than the source system. Third, it can inherit the identity of a service account or workload identity that has more visibility than the task really needs.

This is why the relevant control question is not only “can it write?” but also “what can it observe, infer, and redistribute?” Read-only workflows often rely on delegated access, short-lived tokens, or retrieval tools, so the agent may never modify source records while still expanding the blast radius of sensitive information.

Limit source-system reach to the minimum data slice needed for the task.
Separate query rights from output rights so the agent cannot echo everything it can see.
Review whether the agent’s prompts, tool results, and downstream destinations create implicit re-sharing.
Treat cross-system correlation as a disclosure event, not just an operational convenience.

OWASP’s NHI guidance is useful here because the issue is identity scope, not write permission alone, while the NHI Management Group guide on Ultimate Guide to NHIs is a practical reference for lifecycle, visibility, and excessive privilege concerns. These controls tend to break down when the workflow spans multiple business systems with different data classifications, because the agent can lawfully access each source yet still create an unauthorised composite view.

Common Variations and Edge Cases

Tighter restrictions often reduce usefulness, so teams have to balance analytical value against disclosure risk. That tradeoff becomes more pronounced in support, security, and finance workflows where the whole point of the agent is to summarise scattered information quickly. There is no universal standard for this yet, but current guidance suggests that read-only workflows should be judged by the sensitivity of the resulting output, not by the absence of writes.

Edge cases usually appear when the agent handles indirect disclosure. For example, a workflow that “only” drafts a response may still reveal incident details, customer identifiers, internal hostnames, or access relationships. Another common failure mode is over-broad retrieval: the agent is allowed to inspect a system for context, then faithfully reproduces that context in a less protected channel. That is especially risky when the output is stored, forwarded, or fed into another AI system.

The hardest cases are environments with fragmented service identities, shared accounts, or weak visibility into which machine identity accessed which source. In those settings, read-only access can still become a durable exposure path because the organisation cannot easily prove what the agent saw or where it sent the information.

Risk and Threat Considerations

Read-only AI workflows create material identity risk because they can convert legitimate access into unauthorized disclosure, over-collection, and downstream propagation of sensitive information. The risk class is not privilege escalation through modification; it is privilege expansion through observation, inference, and redistribution.

Failure mechanism: A workload identity or delegated token is granted broad retrieval rights, the agent correlates data across systems, and the resulting answer is delivered into a channel with a wider audience or weaker controls. If prompts, logs, caches, or memory stores retain that output, the exposure can persist beyond the original interaction.

Impact: Sensitive operational data, credentials, internal relationships, or incident context can be exposed to users and systems that were never meant to receive them. The organisation may also lose visibility into which non-human identity accessed which data, making containment, audit, and revocation harder.

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, OWASP Non-Human Identity Top 10, OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-03	Read-only agents still create exposure through excessive visibility and redistributed context.
Recommendation: Limit non-human access to the minimum data scope the workflow genuinely needs.
OWASP Non-Human Identity Top 10	NHI-01	Identity risk depends on knowing which workload identity is querying and sharing data.
Recommendation: Track every service or workload identity that can read and relay sensitive information.
OWASP Non-Human Identity Top 10	NHI-04	Read-only agents often rely on tokens or API keys that can broaden disclosure if mishandled.
Recommendation: Use short-lived credentials and revoke access quickly when the workflow changes.
OWASP Agentic AI Top 10	A1	The issue is what an autonomous agent can observe and emit, not only what it can modify.
Recommendation: Constrain agent permissions by task, context, and output path.
NIST CSF 2.0	PR.AC	Read-only workflows still depend on access scope, delegation, and controlled data retrieval.
Recommendation: Access decisions should reflect the data the agent can expose, not just write rights.

Practitioner Guidance

What to prioritise: Classify read-only workflows by output sensitivity, not by whether they can change source systems. If the agent can combine data from more than one protected system, treat the workflow as a disclosure control problem and review it with the same seriousness as an access-grant change.

What to verify: Confirm which identity the agent uses, what each tool call can retrieve, and where the output can land. The most important check is whether the agent can surface data into a channel that has broader readership, longer retention, or weaker governance than the source system.

Practitioner takeaway: Read-only does not mean low impact when the agent is the one assembling and re-distributing the context; the practical test is whether its output widens who can know something, not just who can edit it.