Using AI Agents Securely: Permissions, Approvals, MCP Servers and Logging

A chat assistant answers; an agent acts. It receives tools, such as file access, email, a shell or APIs, and decides on its own when to call them. OWASP calls the consequence “Excessive Agency” (LLM06:2025): harmful actions in response to unexpected, ambiguous or manipulated model output, regardless of why the model misbehaves. The causes are excessive functionality, excessive permissions and excessive autonomy. The OWASP Top 10 for Agentic Applications 2026 (published on December 9, 2025) extends this with the principle of Least Agency: use agentic behavior where it is needed, because otherwise it enlarges the attack surface without benefit.

1. 1

   Limit tools to what is necessary

   Offer only the extensions the agent needs for its task, and within them only the necessary functions: an agent that summarizes emails needs to read, not send or delete. Avoid open-ended tools such as arbitrary shell commands or URL fetches (OWASP LLM06, mitigations 1 to 3).

2. 2

   Minimize permissions

   Give each tool only the permissions it needs, for example read access to one table instead of the whole database, and run it in the context of the respective user (LLM06, mitigations 4 and 5).

3. 3

   Require approval for consequential actions

   A human confirms high-impact actions before they are executed: sending, deleting, paying, changing permissions, publishing (LLM06, mitigation 6; LLM01, mitigation 5).

4. 4

   Do not leave authorization to the model

   The target system decides according to its own rules whether an action is allowed, not the language model. Every request made through a tool is checked there against the security policy (LLM06, mitigation 7: complete mediation).

5. 5

   Treat third-party content as untrusted

   Websites, documents, emails and tool descriptions from MCP servers can contain instructions. They are processed separately and labeled, and must not trigger actions without review (LLM01, mitigation 6; MCP specification).

6. 6

   Log and limit

   Log and monitor tool calls and actions in target systems, and limit rates and budgets so that misbehavior is noticed before major damage occurs (LLM06; OWASP ASI02, mitigation 5).

An example from OWASP LLM06: an assistant that summarizes emails is built with an extension that can only read, signs in with an OAuth grant limited to read-only scope, and every email it drafts is sent only by the human after review.

• A dedicated identity per agent and task instead of an administrator’s or developer’s personal account; this keeps it traceable who acted (OWASP ASI03).
• Short-lived, narrowly scoped tokens per task instead of permanent keys; cap permissions with boundaries (ASI03, mitigation 1; ASI02: just-in-time and short-lived access).
• Credentials separated and narrowly scoped per MCP server, nothing inherited from your own shell, nothing reused (MCP Local Server Security, checklist).
• MCP servers must not accept tokens that were not explicitly issued for them and must not pass tokens on to downstream APIs unchecked (MCP Security Best Practices: Token Passthrough, “MUST NOT”).
• Secrets belong in a vault or the system’s credential manager, not in prompts, chat histories or configuration files in the repository.
• It must be possible to revoke and renew an agent’s access centrally if it behaves suspiciously (ASI04 and ASI10: kill switch and credential revocation).

MCP servers provide an agent with tools, data and prompts. The specification (version 2026-07-28) states: tools represent arbitrary code execution and must be treated with appropriate caution; descriptions of tool behavior are considered untrusted unless they come from a trusted server; hosts must obtain explicit user consent before invoking any tool. The protocol cannot enforce these principles itself; applications must do so.

• Does the server need local files, tools or the local network? If not, use the remote version over Streamable HTTP with authorization instead of a local process
• Publisher identified, source code available for review, exact package name checked (typosquatting packages), version pinned
• With launchers such as npx or uvx, keep in mind that the version specifier pins only the top-level package; a container image with a digest freezes all dependencies
• Tool descriptions read before use; servers with foreign instructions in descriptions removed; client asks again when tools change
• Third-party servers isolated in a container, sandbox or virtual machine, without unnecessary volume mounts
• File access limited to specific directories, read-only where possible
• Outbound network traffic blocked or limited to a known list of destinations
• Only as many servers as necessary, because all configured servers share the same model context
• In the organization: list of approved servers with criteria, ongoing inventory of client configurations, logs of MCP activity, servers can be blocked centrally

The checkpoints follow the “Local Server Security” guide in the MCP documentation (version 2026-07-28). It calls process isolation the most effective single measure, because it protects even when the provenance check fails.

The example describes features according to the vendor documentation; it is not an assessment or endorsement of a product. Anthropic itself points out that no system is immune to all attacks and that suggestions should be reviewed before approval.

Regardless of the stage, Art. 4 of the AI Act as amended by Regulation (EU) 2026/1744 requires providers and deployers to take measures to support the AI literacy of the people working with AI systems on their behalf. Anyone who approves or monitors agents must know their limits.

• The agent’s task, limits and responsible person defined in writing
• Agentic behavior is necessary for the task; simpler, fixed workflows were considered
• Only necessary tools and functions enabled, no open shell or fetch tools without good reason
• Dedicated identity with least privilege, short-lived access, no shared administrator accounts
• Consequential actions require human approval; the list of these actions is defined
• Target systems check every request against their own permissions
• Third-party content is treated as untrusted; tests with injected instructions carried out
• MCP servers vetted for provenance, version pinned, isolated, with their own narrowly scoped access
• Network access of the agent and its tools limited to known destinations
• All tool calls and actions logged, analysis and retention defined
• Budgets and rate limits set, kill switch and access revocation tested
• Data protection reviewed: legal basis, contract with the provider, data protection impact assessment if required
• Users trained; reporting path for suspicious behavior known

This checklist is a TOMORIS recommendation based on the OWASP and MCP publications listed; it does not replace a security test of the specific agent.