Do your agent platforms have one governed path to company systems?

Surface

Where agents run decides which controls you can put in front of them.

• IDE agent, mostly read-only · Useful for code help, but usually bounded to one developer session.
• IDE or CLI agent with tools · Can call local tools, scripts, or MCP servers from a developer environment.
• Slack or Teams agent · Work starts in chat, where requester, context, and approver may already be present.
• MCP or tool gateway · A central surface exposes tools, resources, or actions to agent clients.
• Custom workflow agent · A headless or scheduled agent runs repeatable work across systems.
• Enterprise workspace agent · Shared agents run company workflows across docs, chat, and business tools.
• No standard agent surface yet · Individual teams are experimenting without a common rollout model.

Autonomy

The highest-risk action an agent can reach sets how much of the rest has to be in place.

• Read-only recommendations · The agent can inspect or summarize, but cannot prepare changes.
• Can prepare changes · The agent can draft PRs, commands, tickets, or updates for a human to apply.
• Writes after approval · The agent can act only after an explicit human gate.
• Autonomous write actions · Some writes can happen without approval.
• Destructive or production actions · Deploys, deletes, rollbacks, permission changes, or production operations are in reach.

Identity and authority

An agent should carry a person’s authority, not a shared key, so its access ends when theirs does.

• Unknown / varies by team · Different tools use different credentials or nobody has mapped it.
• Shared bot credential · The agent acts as the installed app or service account.
• Copied human token · A user token or API key is placed into the agent environment.
• Delegated user authority · The agent acts on behalf of the requester with their approved scope.
• Per-agent identity · Each agent has its own identity and credential lifecycle.
• Per-workflow identity · Authority is scoped to a task, workflow, or run context.

Revocation

If you cannot cut an agent off quickly, every other control assumes nothing goes wrong.

• No reliable revocation · Access remains until tokens expire or someone manually cleans it up.
• Token expiry only · Revocation depends on TTLs rather than policy changes.
• Manual disable path · Admins can disable an agent or integration after finding it.
• Policy-based revocation · Changing policy removes tool access for affected sessions.
• Live session heartbeat · In-flight sessions lose access quickly when policy changes.

Tool scope

Agents that can discover every tool will eventually use one you did not mean them to.

• Unknown / local by team · Tool exposure depends on each user or team setup.
• Local MCP servers · Developers install or configure MCP servers individually.
• Approved server registry · Teams pick from a reviewed list of MCP servers and tools.
• Central gateway · A shared control point exposes tools to agent clients.
• User/team allowlists · Tools are exposed by user, group, project, or tenant.
• Read/write/delete classes · Actions are separated by risk, not only by integration.
• Dangerous actions gated · Deploy, delete, permission, prod, and data-export actions can be blocked or approved.

MCP review

Each MCP server is new code with access to your systems. Someone should look at it before agents do.

• No MCP review yet · New tools can appear without owner, auth, or metadata review.
• Tool metadata review · Descriptions, hidden instructions, and tool contracts are checked.
• Auth required for servers · Remote MCP servers require explicit authentication and authorization.
• Named owner review · Each server or tool has a responsible owner.
• Change review · Server/tool changes are reviewed before rollout.

Context boundary

What an agent can read decides what it can leak into a prompt, a ticket or a reply.

• Current repo or file only · The agent sees local code context, but not the wider engineering graph.
• Attached docs only · Users manually provide docs, tickets, or snippets.
• Search across systems · The agent can search docs, tickets, chat, code, or incidents.
• Cross-system graph · Relationships connect code, tickets, incidents, docs, owners, and prior decisions.
• Tenant/project scope · Context is filtered by tenant, team, project, or user policy.
• Sensitive-data aware · Secrets, PII, customer data, and protected systems have extra controls.
• Unknown / inconsistent · Context access differs by tool, user, or environment.

Approvals

Approvals belong in front of the actions that are hard to take back.

• No approval gates · The agent can act whenever its tool has permission.
• Writes require approval · Create/update operations pause before execution.
• Destructive actions require approval · Deletes, production actions, and privilege changes are gated.
• Policy by action and resource · Approval rules depend on action type, tool, resource, and environment.
• Routed to owner or approver · Approvals go to the person or team responsible for the resource.
• Approval includes diff and reason · Approvers see what will change and why.
• Decision is logged · Approval, rejection, approver, context, and result are recorded.

Audit

You need to be able to say what an agent did, for whom, and why it was allowed.

• No central run record · Evidence is scattered across prompts, chat, logs, and tool histories.
• Prompt and response logs · Conversation is visible, but tool/action proof is thin.
• Tool-call trace · Each tool call, arguments, and result are captured.
• User/agent/workflow attribution · Runs connect requester, agent, workflow, tenant, tool, and resource.
• Approval chain · Human gates are tied to the run and final outcome.
• SIEM or OTel export · Security and platform teams can route events to approved collectors.
• Replayable execution report · A reviewer can reconstruct what happened without asking the agent owner.

Lifecycle and spend

Pilots end. Agents nobody owns keep running and keep spending.

• No TTL or budget model · Access and spend are reviewed after the fact.
• Session-bound access · Access expires with the login or conversation session.
• Task-bound access · Access ends when the ticket, incident, PR, or request closes.
• Time-boxed grants · Temporary access expires after a fixed window.
• Owner recertification · Owners periodically renew agents, tools, and policies.
• Auto-deprovisioning · Access is removed when users, groups, tools, or owners change.
• Workflow/run budgets · Tokens, tool calls, or credits are attributed to a workflow or team.
• Cost anomaly review · Unexpected run volume or token spend gets flagged.

What has to be in place before AI agents leave a pilot?

A way to tie each agent to a person, a way to revoke it fast, a limit on which tools it can use, approvals in front of irreversible actions, and a record of what it did. Spend and ownership come next.

Do MCP servers need a security review?

Yes. An MCP server is code that runs with access to your systems. Review what it exposes and pin the version you reviewed.