MCP security

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 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 apply to the calls behind each tool as well.