---
title: MCP security
description: How keys, scopes, project tokens, confirmation and the activity log keep an agent within the limits you set.
section: Agents
order: 4
updated: 2026-11-04
---

An agent connected to Dekka acts as the person who created its key, within that key's scopes and that person's role. It goes through the same API, permission checks, plan limits and validation as the dashboard, so it can never do more than the key's owner could.

## Choose the scope

| Scope | Tools the agent sees | Use it when |
| --- | --- | --- |
| read | Projects, services, deployments, logs, metrics, variables with secrets hidden, templates and docs | You want answers and investigation, with no chance of a change |
| write | Everything in read, plus creating services, deploying, setting variables, restarting, adding databases and domains, and planning and applying templates | You want the agent to build and ship |
| admin | Everything, including deleting services and variables and revealing connection strings | You need the agent to clean up or hand out credentials |

A key's scope is a ceiling on its owner's role. A developer's admin key still can't do what only an owner can. Tools a key can't use don't appear in its list at all, and calling one by name fails as if it didn't exist.

## Limit it to one project

A [project token](/docs/project-tokens) reaches one project and nothing else in the organisation. It can hold read or write but never admin, so it can't delete services. Choose a project in the **Agents** tab, or create a token in the project's settings, when an agent works on a single app.

## Read-only sessions

Adding `?read_only=true` to the server address hides every write and admin tool for that connection, whatever the key allows. Use it when you want an agent to look into a problem without fixing anything yet.

## Confirmation

Tools that can't be undone, which are `delete_service`, `delete_variable`, `rollback` and `apply_changes`, return a preview unless they're called with `confirm: true`. Plans for templates, blueprints and Compose files change nothing until they're applied. Most clients ask before running a tool, and you can tell an agent to always show you the preview and wait for a yes.

## Secrets

Secret and sealed variables are never returned. `list_variables` shows `(secret)` in their place, and planned changes never contain values. Generated secrets in templates are created on Dekka and are never sent to the agent. The only way to read a credential is `get_connection_strings` with `reveal`, which needs admin and is recorded in the activity log each time.

## Prompt injection

An agent reads text it doesn't control, such as build logs, commit messages, README files and web pages, and that text can contain instructions meant to steer it. Treat the agent's key as the limit of what such text could make it do.

- Give the agent the narrowest key that does the job, and prefer read-only while it investigates.
- Use a project token so a mistake can't reach other projects.
- Read previews before you confirm deletes, rollbacks and applied plans.
- Don't connect a write key in the same session as tools that browse untrusted sites, unless you review each call.

## Audit

Every change an agent makes is recorded in the organisation's activity log with the key that made it and a note that it came from the MCP server. The key's **last used** time in **Settings → API keys** shows when it was last active.

## Revoke a key

Revoke a key under **Settings → API keys**, or a project token in the project's settings. The next request from the agent is refused straight away. Keys you create in the **Agents** tab expire after 90 days unless you choose otherwise.

## Rate limits

Each key can make 240 tool calls a minute. An agent that goes over gets a message saying how long to wait, and the API's own [limits](/docs/limits) apply to the calls behind each tool as well.