Who is accountable for documenting data flows and access paths in agentic AI systems?

Security, engineering, and governance teams are all accountable for keeping data flow documentation current. If AI agents can access sensitive data or trigger external actions, the organisation needs an auditable view of what connects to what, which systems touch the data, and where the highest risk paths exist. Without that, compliance and incident review suffer.

Why This Matters for Security Teams

In agentic ai systems, documenting data flows and access paths is not just a compliance exercise. It is the only practical way to answer basic operational questions when an autonomous agent moves data, calls tools, or triggers external actions. Current guidance suggests treating the agent as a workload with its own identity, not as a user proxy with a neat permission set, which is why static diagrams age quickly.

This is especially important because agent behaviour is dynamic: the same prompt can lead to different tool calls, data retrieval paths, and downstream effects depending on context. When teams cannot show what data the agent touched, they cannot reliably investigate misuse, enforce least privilege, or prove containment after an incident. That is why NIST’s NIST AI Risk Management Framework and OWASP’s OWASP Agentic AI Top 10 both push organisations toward explicit governance, traceability, and runtime control.

NHIMG research shows the scale of the visibility gap: in the AI Agents: The New Attack Surface report, only 52% of companies could track and audit the data their AI agents access. In practice, many security teams discover undocumented access paths only after an agent has already shared data, crossed a trust boundary, or executed an unauthorised action.

How It Works in Practice

Accountability should be shared, but the work has to be coordinated. Security owns the control model and the evidence requirements, engineering owns the implementation details, and governance owns the policy that defines what must be documented, reviewed, and retained. For agentic systems, the documentation needs to be live enough to reflect runtime behaviour, not a one-time architecture sketch.

Practically, teams should document three layers. First, the data sources and destinations: what the agent can read, write, or exfiltrate. Second, the access path: which workload identity, service account, API token, or brokered secret enables each connection. Third, the decision path: which policy or approval step allows the action at request time. That is where real-time policy evaluation matters, and where frameworks such as CSA MAESTRO agentic AI threat modeling framework and the OWASP Non-Human Identity Top 10 are useful as operational references.

• Map each agent to a workload identity and the systems it can reach.
• Record whether access is persistent, just-in-time, or conditional on runtime policy.
• Log the data classification attached to each flow, including sensitive or regulated content.
• Capture the tool chain so chained actions can be traced after the fact.
• Review the map whenever prompts, tools, connectors, or secrets change.

For implementation detail, align the documentation with real telemetry from identity providers, orchestration logs, and data loss prevention tooling. NHIMG’s Ultimate Guide to NHIs is a useful reminder that NHI governance fails when credentials, identities, and permissions drift apart from the systems that use them. These controls tend to break down when agents can self-chain across multiple tools and produce different access paths on each run because the documentation no longer matches the live control plane.

Common Variations and Edge Cases

Tighter documentation often increases operational overhead, requiring organisations to balance traceability against the speed of model and workflow changes. Best practice is evolving here, and there is no universal standard for how much detail is enough, especially in fast-moving environments with many agents and frequent connector changes.

The main edge case is low-code or no-code agent builders. These environments often hide the real access path behind abstractions, so the diagram shown to business owners can differ from the actual identity, token, and data path used at runtime. Another common exception is delegated access, where an agent acts on behalf of a human. That does not remove accountability; it adds another hop that must be documented, particularly when an agent can access calendars, inboxes, repositories, or customer records.

Current guidance suggests treating prompt injection, tool abuse, and over-broad secret reuse as documentation triggers, not just security incidents. NHIMG case studies like Replit AI Tool Database Deletion and CoPhish OAuth Token Theft via Copilot Studio show why access-path documentation has to include failure modes, not only intended design. Where agents operate across regulated data, external SaaS, and internal APIs, the documentation burden is highest because small changes can create new paths that no one reviewed.

Related resources from NHI Mgmt Group

• Who is accountable when OAuth flows are used in AI agent access paths?
• Who is accountable when inappropriate data access is detected in an identity security program?
• Who is accountable when AI agents and other non-human identities make access decisions that create risk?
• What makes agentic AI an NHI governance issue?