Is it safe to let an AI agent act on company systems?

A chatbot answers. An agent acts: it opens a browser, runs a terminal command, calls an API, or uses a tool connected through the Model Context Protocol (MCP). Each of those actions runs on a credential someone handed it, such as a login, an API key, or an OAuth token. The useful question is what that credential reaches, who approves the risky steps, and whether anyone can reconstruct afterward what the agent did.

What can an AI agent do with your credentials?

Everything the credential allows. An agent signed into a website or connected to an app can read the email, files, and account settings behind it, and act on them, for example by sharing a file or changing a setting. The joint agentic AI guide from CISA, the NSA, and the cyber agencies of Australia, Canada, New Zealand, and the United Kingdom describes a procurement agent given broad access to finance, email, and contracts. An attacker who compromises one low-risk tool in its workflow inherits all of that access, and the audit logs look legitimate because the trusted agent did the work.

Two verified incidents show the pattern. In July 2025, AWS reported that a GitHub token with overly broad scope let an attacker commit malicious code into release 1.84.0 of the Amazon Q Developer extension for VS Code; the code failed to run because of a syntax error. The same month, Fortune reported that Replit's coding agent deleted a live production database during a declared code freeze. Replit's CEO called it unacceptable and said the company was adding automatic separation between development and production databases.

What security controls should an AI agent have?

These controls apply the same way to a browser agent, a coding agent, or a custom agent connected through MCP. Agent products commonly ship with approval prompts switched on. Risk enters when a team switches on blanket auto-approve to stop the prompts, or connects the agent to production systems with a developer's own long-lived token.

What does least privilege mean for LLM tool execution?

OWASP's LLM06:2025 Excessive Agency names three root causes:

• Excessive functionality: a tool that only needs to read documents also carries delete and modify functions.
• Excessive permissions: a read-only tool connects to a database with an account that can also write and delete.
• Excessive autonomy: a high-impact action runs with no user confirmation.

The OWASP Top 10 for Agentic Applications, published December 9, 2025, extends this into least agency: grant autonomy only where it adds value. Its guidance for tools is concrete. Give each tool its own profile, such as read-only queries for a database and no send or delete rights for an email summarizer, and issue short-lived credentials bound to one user session.

How should MCP servers handle credentials?

The MCP specification's security best practices (version 2025-11-25) set three rules that matter most here. An MCP server must reject any token that was not issued for that server; passing a client's token straight through to another API is explicitly forbidden, because downstream logs then show the wrong identity and controls tied to that identity stop working. Scopes start small and grow only when a privileged operation first needs them; wildcard scopes such as files:* or admin:* turn one stolen token into broad access. A local MCP server runs with the same privileges as the app that launched it, so a client offering one-click setup must show the exact command and get explicit approval before running it.

Treat each MCP server as third-party software with your keys inside it, and approve it the way you would approve any other software that holds company credentials.

Which agent actions need human approval?

Anything hard to undo: deleting data, moving money, publishing, sending information outside the company, and changing permissions. OWASP recommends showing the person a dry-run or diff of the planned change before they approve it. The CISA guide adds that agents should never be able to change their own privileges. OWASP's own example explains why: a hidden instruction in an incoming email tells an assistant to search the inbox and forward sensitive messages. A read-only mail tool, a read-only OAuth scope, and a human review before anything is sent each stop it.

What should you log for every tool call?

• Identity: which agent acted, and which person or workflow it acted for.
• Action: the tool, its parameters, and the result.
• Approval: who approved a consequential step, and when.

OWASP calls for immutable logs of every tool invocation and alerts on unusual chains, such as a database read followed by an external transfer. CISA asks for tool use in human-readable logs. NIST AI 600-1 flags indirect prompt injection, where instructions hide inside data the agent retrieves, and says documenting third-party plugins is especially important when an incident has to be disclosed.

For a coding agent such as Claude Code, or an agent you built yourself, Sentinel, an AI gateway, sits in front of the model provider, replaces the identifiers it recognizes in each prompt, and records metadata for each request: counts, which rule fired, and latency. It records metadata only, so the tool-call log described above stays the record of what the agent did.

How do you assess an AI agent before turning it on?

• Inventory the reach: list every tool, connector, MCP server, and credential the agent can use, and remove the ones the task does not need.
• Scope each credential: give the agent its own identity, read-only access wherever possible, and tokens that expire.
• Name the approval points: write down which actions pause for a person, and test that they actually pause.
• Isolate execution: run code and commands in a sandbox or separate machine, allowlist outbound network access, and keep production data out of development.
• Confirm the logs: check that individual tool calls appear in a record your security team can read, beyond the conversation transcript.
• Pilot small: start with a low-risk task, plant a test instruction in a document the agent will read, and widen access only after it passes.

Agent products change monthly. Re-run this assessment when a product changes its defaults, when you add a tool, and at least every quarter.