What an AI inventory can't tell you
The register says Claude Code is approved. It doesn't say which credential the agent runs on, what it can reach, or who pulls access when it does something it shouldn't.
On this page9 sections
The register is the easy part
Most security teams start AI governance with a list. ChatGPT Enterprise, Microsoft 365 Copilot, Claude Code, Cursor, and the meeting note-taker someone in sales signed up for with a corporate card. Each row gets an owner and a business purpose. That is real work. Finding the note-taker nobody had heard of is a genuine win.
The trouble starts when the finished list gets reported upward as AI security. A row that says ChatGPT is approved doesn't tell you whether the analyst pasting a forecast into it is signed in to the company workspace or to the personal Gmail-login account they've had since college.
Approval is attached to a use. Say legal approves an assistant to summarize contracts in one SharePoint folder, on company accounts. Six months later someone connects the same assistant with permission to share files outside the tenant. Same vendor. Same row in the register. Different decision.
Keep the inventory. An AI security posture management program can't work without one. But the list has to feed real answers. Which account is in use, which data the connection reaches, which actions it can take, and who pulls access when something goes wrong.
An approval covers a specific account and scope. Nothing wider.
Trace the chain, link by link
A chain that works as a review guide: Human → AI application → Agent → MCP server → Skill or plugin → Tool → Data → Action. Real workflows skip links and branch. A Copilot Studio agent might call a connector directly with no MCP server involved. A coding agent might hand a subtask to a second agent. Follow what's actually there. Where the Model Context Protocol is involved, a server exposes tools the model can call against outside systems.
Questions worth asking at each link:
- Human: who asked for the work, and who answers for it if it goes wrong. Often two different people.
- AI application: which account and which workspace. Company tenant or personal login.
- Agent: the identity it acts under. The engineer who starts a Claude Code session and the API token that session uses can carry very different permissions.
- MCP server: where it's configured and who added it. A single line in ~/.cursor/mcp.json on one laptop counts. The MCP tools specification says a human should always be able to deny a tool invocation. It doesn't say which human.
- Skills and plugins: what they change about how the agent works, who maintains them, and which update sends them back for review.
- Tool, data and action: the operation, its target and the consequence. Reading a draft, exporting a customer record and deleting a repository are different decisions, even when the same assistant would run all of them.
Say an engineer opens Claude Code to fix a billing bug
Claude Code is in the register with an owner in platform engineering. The engineer points it at the billing service repo. The project's .mcp.json connects a support-ticket MCP server so the agent can pull the customer's complaint. A debugging skill tells it how to gather logs.
On paper this is tidy. Every component has a row. Underneath, the ticket server authenticates with a token that can read every customer's tickets and post replies as the support team. The repo also has a .env file with a production database password that someone copied in during an outage and never removed. Unless someone set a deny rule, the agent can read that file like any other.
The fix needs the code, a few log lines and one customer's ticket. It doesn't need every customer's history. It doesn't need to reply to anyone. It definitely doesn't need production. Approving Claude Code approved none of that.
So test it. Can the agent pull an unrelated customer's ticket? Read the .env? Post a reply without anyone clicking approve? Send what it collected to an outside URL? Each yes is a path to harm. None of them is evidence that harm happened, and mixing the two up is how a cleanup ticket becomes a declared incident.
The fix is unglamorous, which is typical of coding agent security work. Scope the ticket token to read-only on tickets assigned to the engineer. Pull the production password out of the repo and rotate it. Require approval before anything posts to a customer. Then rerun the same task. The bug should still get fixed. The out-of-scope attempts should fail.
Whether last Tuesday's run already pulled other customers' tickets is a separate question. Answering it depends on records you may not have.
What it can do, what it did
Reviews go soft when four ideas get squashed into one risk score. Access is what an identity can reach. Capability is what it can do there. Behavior is what happened on a given run. Exposure is the damage the first two allow if something goes wrong.
Take an agent with access to a Google shared drive, permission to change sharing settings, and a month of logs showing it only ever read project notes. Its behavior is narrow. Its authority isn't. Quiet logs don't make the unused permission safe.
It cuts the other way too. A blocked attempt to edit a protected file is not an edit. When you investigate, keep the requested action, the target, the authorization decision and the result as separate facts.
The OWASP Top 10 for LLM Applications lists excessive agency as LLM06:2025 and traces it to excessive functionality, excessive permissions and excessive autonomy. As review questions: Does the task need this tool? Does the tool need this access? Should this action run without a person saying yes?
Start with paths that touch customer data, change identities or delete things. Familiar apps included.
What an agent can do and what it did are separate facts.
Whose credential actually reached the data
One AI app can show up in five places. The ChatGPT tab in Chrome. The desktop client. A Slack integration. An OAuth grant in Google Workspace that a product manager clicked through. A service account a developer made for a nightly script. Those might belong to one person, to several, or to nobody in particular.
For each connection, write down the human owner, the identity the agent acts as, and where that identity's authority comes from. They often differ. An employee asking for work doesn't mean the agent runs with that employee's permissions. It may run on an app-level grant, a service account or a long-lived API key sitting in a CI secret. The credential that reaches the resource is the one to review.
Picture a Google Workspace admin going through third-party app access. A grant to an AI meeting assistant reads one user's mail and calendar. The register lists that assistant as approved for the sales team. The user who granted it works in legal. That is an AI agent identity problem, and the inventory row looks fine.
Build an AI audit trail that ties the request, the acting account, the tool calls and the outcome together where you have evidence. Where you don't, say so. If a shared API key means you can't tell which engineer ran the agent, record that. Don't assign an owner just because the field is empty.
Identity also tells you what to pull during a response. Killing a local process, removing an app grant and revoking a user's sessions shut off different things. Pick the one that matches the authority involved. Then check.
Ask for a demo
Questionnaires are fine prep. They can't show you that a prohibited action actually gets refused. Ask the workflow owner to run the real task with test data while you watch, and walk the chain together.
When a SOC 2 auditor asks how you control what agents can reach, a recorded failed attempt is a better answer than a policy PDF.
Use the table at onboarding and again whenever something on the chain changes.
Link in the chain
Human and account
- Ask to see
- The account in use, and whether it's the company workspace or a personal login.
- Decide
- Allow, move to the company workspace, or stop.
Link in the chain
Agent identity
- Ask to see
- The token, service account or grant the agent runs as, with its scopes.
- Decide
- Cut scopes the task doesn't use.
Link in the chain
MCP servers, skills, plugins
- Ask to see
- The config files, who added each entry and who maintains it.
- Decide
- Keep what's needed. Set which updates trigger another review.
Link in the chain
Tools and data
- Ask to see
- The operations each tool supports and where output can go.
- Decide
- Limit writes, exports and outbound messages.
Link in the chain
Actions
- Ask to see
- A live attempt at one allowed action and one prohibited action.
- Decide
- Where a person has to approve.
Link in the chain
Response
- Ask to see
- Run records and a test revocation you confirm took effect.
- Decide
- Who investigates and who can pull access.
Done means someone can explain the boundary and show it holding.
The register goes stale on a Friday
A developer adds a Postgres MCP server to their Cursor config before a Friday release because it saves them a trip to the database console. A support lead approves a new Zendesk scope for an AI drafting tool. Neither creates a new row. Both change what the review said.
Trigger reviews on changes in authority. A review date tells you when someone last looked. It says nothing about whether the boundary they approved still exists.
Write policy an operator can test. "Use AI responsibly" can't be tested. "This assistant can read the Q4 planning folder and needs approval before sending anything to an external address" can. Apply least privilege to the connections behind each action, and make approval prompts show the actual action and target. Saying yes at the start of a task shouldn't quietly cover whatever the agent decides to do two hours in.
Practice the response before you need it. Who can stop a running agent at 11pm? Who can revoke the grant? When they do, did access actually go away, or did someone just file the request?
From Identra
How Identra helps
Identra discovers AI apps and the accounts people use with them, so a work login and a personal login show up as different things. It finds coding agents, MCP servers, skills and plugins on employee machines, and AI agents in Microsoft 365 Copilot and Foundry, Google Workspace and Anthropic, with their owners. Where the person is known, it all lands on one timeline for that person.
Connected apps are sorted by what they can reach. AI agent tool calls are checked against policy, and destructive shell commands are denied when policy is set to block. Analysts can revoke risky OAuth grants, and sign-in sessions with approval. Each response records its result.
Frequently asked questions
Is an AI inventory still worth building?
Yes. It's where every review starts. Add the acting identity, the grants, the connected tools and who owns response, and it starts supporting real decisions.
If we approve a vendor, is every use of its app approved?
No. ChatGPT Enterprise on the company workspace and a personal ChatGPT login are different risks. Approve a specific account, workspace, data scope and set of actions. A new connection or a wider permission reopens the review.
Does every AI workflow involve MCP servers, skills or plugins?
No. Treat the chain as a review guide and follow the connections the workflow actually has, including direct API integrations and handoffs to other agents.
Where should a security team start?
Pick one workflow that touches customer data or can change production. Find the credential it really runs on and cut what it doesn't need. Then watch someone try an allowed action and a prohibited one.
Related terms
Solutions
See it in your environment
AI security built on identity. One timeline.
A walkthrough with a security engineer.