What is the difference between governing AI agents with an access graph and managing them in spreadsheets?

Why This Matters for Security Teams

An access graph changes the governing question from “what assets exist?” to “what can reach what, right now, and through which identity path?” That matters for AI agents because their access is not static. Agents can chain tools, inherit tokens, and pivot across services in ways that a spreadsheet cannot model with any reliability. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime visibility, because autonomous behaviour makes precomputed inventories incomplete almost as soon as they are captured.

The practical issue is that spreadsheets describe intent, while attack paths emerge from relationships. A row for an agent, a column for a secret, and a tab for a target system do not show whether the agent can combine those elements into a destructive action. NHIMG research on the OWASP NHI Top 10 and incidents such as the CoPhish OAuth Token Theft via Copilot Studio shows why access paths, not just asset lists, determine exposure. In practice, many security teams encounter privilege chains only after an agent has already used them, rather than through intentional review.

How It Works in Practice

An access graph is a live model of identity and reachability. It maps agents, humans, models, secrets, service accounts, APIs, and data stores as connected nodes, then records the permissions and trust relationships between them. For agentic systems, that usually means linking workload identity to runtime authorisation, not merely logging usernames and static roles. Practitioners increasingly pair this with policy-as-code and short-lived credentials, because the graph becomes useful only when it can answer “is this agent allowed to do this task now?” rather than “was it once approved?”

In practice, teams use the graph to support reviews such as:

• Which agents can access production data, and through which token or delegated credential?
• Which secrets are reusable across multiple agents, tools, or environments?
• Which human approvals are required before an agent can escalate privilege?
• Which connections persist after the task ends, and should be revoked immediately?

This is where the difference from spreadsheets becomes operational. A spreadsheet can record that an agent exists, but it cannot continuously recalculate the risk that arises when the agent receives a new prompt, a new tool, or a new secret. Research from The State of Secrets in AppSec highlights how fragmented secrets management already is, and that fragmentation becomes more dangerous when autonomy is added. The implementation pattern aligns with CSA MAESTRO agentic AI threat modeling framework, which treats agent behaviour as dynamic, contextual, and policy-driven. These controls tend to break down when agents are allowed broad standing credentials across multiple production systems because the graph then reflects accumulated privilege, not bounded task access.

Common Variations and Edge Cases

Tighter graph-based governance often increases operational overhead, requiring organisations to balance visibility against change-management friction. Not every environment needs the same level of graph precision, and current guidance suggests the right depth depends on the blast radius of the agent. A low-risk internal assistant may only need coarse relationships, while a code-writing or ticket-executing agent needs far richer mapping of tool access, delegated rights, and secret lineage.

There is no universal standard for this yet, but a few patterns are clear. First, spreadsheets can still work as a transition artifact for small inventories, but they should not be treated as the system of record once agents have runtime access to tools or production data. Second, graph accuracy depends on continuous discovery. If identity, secrets, and tool permissions are not refreshed in near real time, the graph becomes another stale document. Third, some edge cases require human exception handling, especially during incident response or break-glass access, where temporary connections may not fit normal policy paths. For examples of how rapidly agent trust can be abused, see NHIMG reporting on the Replit AI Tool Database Deletion and the Analysis of Claude Code Security. Spreadsheets fail most visibly in fast-changing environments where agent permissions, secrets, and tool chains mutate faster than manual review can keep up.

Related resources from NHI Mgmt Group

• What is the difference between governing human access and governing AI agent access?
• What is the difference between managed identities and hardcoded secrets for AI agents?
• What is the difference between workload identity and API keys for AI agents?
• What is the difference between logging actions and logging intent for AI agents?