Audit Agent Data Access in One Week

Agent access is now a funded category

Your agents already have paths to data you have not reviewed. Cymphony's work found about 85,000 AI-accessible files at one U.S. public company. Cymphony launched with $30 million in financing on September 9, 2026, with Sequoia Capital and SMBC Fin Atlas Beyond Fund named as co-leaders. The total included a $25 million Series A, which accounted for most of the money.

The product is built around a workforce security graph, a single map that connects identities, permissions, sensitive data, and activity. The platform does not require endpoint installation and can be deployed in one day. Syngenta, KKR, Cass Information Systems, and Athennian were named as early customers, and Sequoia Capital also runs the software internally.

The audit is the part you can run this week. Untracked tools make the problem worse. Vendors will sell the map as a product. Operators need the map as a process. The process can answer the question before an incident asks it. The question is simple: what can this agent reach? The answer must be specific enough to revoke.

Trace the path, not the policy

Agent identity is the category that covers agents, service accounts, and machine tokens. A human user has a badge, a login, and a manager. An agent may have a service account, an API key, a token, and a chain of inherited roles. The map needs edges: identity to permission, permission to data, data to sensitivity, and activity to risk. You do not need a new platform to start. You need the same questions the vendor answers.

Ask which agent can read the file. Name the role that granted it. Check whether the path was used recently. Access control fails when the answer is an assumption. Start with the data you already label sensitive. Then work outward to the agents that can reach it. Check the identity provider for service accounts. Look in the cloud console for roles. Scan the data catalog for labels. Trace the API gateway for routes. The deliverable is a path, not a policy name. A policy name tells you what was intended. A path tells you what is reachable.

Look for common leaks: a service account created for a test job still holds a production role, shared keys get copied into workspaces and are never rotated, and roles get granted to groups that agents inherit through membership. A leak is a path. The path needs an owner. The owner needs a date.

Use the labels you already have. A field marked sensitive is treated as sensitive. A bucket marked private is treated as private. Unmarked data gets marked during the audit. Treat the audit as a reachability test. You are not deciding what the data means. You are deciding who can touch it.

Run the one-week audit

Keep the list below. Each item is a yes-or-no test. If the answer is no, you have found the gap. The first items build the inventory. The middle items trace the path. Removal comes last.

• Every agent identity, including service accounts and API keys, is listed.
• Each identity has a named permission source.
• Permissions trace to reachable data stores or APIs.
• Reachable data sets carry sensitive or non-sensitive labels.
• Recent activity is visible for each active path.
• Inherited access that no longer matches the agent's job is flagged.
• A stale permission is removed, and the approver is recorded.

Identity exposes unlisted agents. Permissions reveal drifted roles. Traces show broad grants. Activity shows dead paths. Removal makes the audit real.

Make removal the deliverable

An access map that ends in a summary is a report, not a control. Remove the stale permission. Revoke the key. Close the path. Assign an owner to the agent. Assign a review date. If the agent cannot justify the access, the access goes. Record the removal in the same log as the inventory. Record the owner, the date, and the reason for the removal.

Make the removal visible. Put the agent name, data path, and approver in the ticket. A future operator should be able to read it and understand why the access changed. Do not leave the decision in a chat thread. Do not leave it in a single engineer's notes.

Keep the audit repeatable. Store the inventory, paths, and removals in a place the team can query. A future audit should start from the last state, not from memory.