Security

This page is the reference for how Monk handles credentials, secrets and approvals. Other pages link here and don’t repeat it.

​

Credentials go through local forms

When Monk needs a cloud key, an API token or a certificate, it opens a form in the local dashboard at http://127.0.0.1:7419. You type or upload the value there. Don’t paste credentials into the chat with your coding agent. The tools that list or check credentials and secrets return names and metadata, never the values. Monk asks for credentials for:

• Cloud providers: AWS, GCP, Azure, DigitalOcean, Hetzner
• Services: GitHub, Netlify, Vercel, Cloudflare, Neon, Auth0, Stripe, MongoDB Atlas, Redis Cloud, DigitalOcean Spaces, and a Slack webhook for Watcher

Obtaining credentials explains what each provider needs. You can see which credentials are stored, and delete them, at any time.

​

Where secrets are stored

The local vault uses your operating system’s credential store: the macOS Keychain, the Linux Secret Service, or Windows DPAPI. Where none is available, it uses an encrypted file. Writing to a cluster scope asks for your approval. Monk can also push named secrets from your local vault to a cluster scope. You name each secret to push, because there is no bulk push, and you approve it in the dashboard. Organization and account secrets reach every matching cluster. At deploy time, the secrets listed in the MANIFEST are injected into the services that use them. Some secrets also go to GitHub. CI/CD and preview environments store a cluster token or API key, cluster connection details and, for previews, cloud credentials as GitHub Actions secrets. The setup screen lists them before anything is created or pushed.

​

What needs your approval

Monk’s tools ask for approval in the local dashboard before they:

• deploy anything that would change what’s running
• create, grow or delete a cluster, remove a node, or upgrade the orchestrator
• write, push or remove secrets at a cluster scope
• set up CI/CD, preview environments or Watcher
• run a custom action on a workload, unless you chose to always allow that action in this workspace
• change roles and role assignments, or billing alerts
• delete or purge workloads, environments or projects

The approval is handled by Monk’s tools, not decided by a model. Permission checks also run in the tools: if your role in an organization doesn’t allow an action, the tool refuses it. See Teams and access.

​

What Monk’s tools do and don’t do

Monk’s tools:

• validate each request against a fixed schema before acting
• read and write only inside the workspace they are bound to, and refuse paths that lead outside it through links
• refuse custom workload actions that the package doesn’t declare
• never return secret or credential values in their responses

Monk doesn’t edit your application code. Your coding agent writes the MANIFEST, templates and Dockerfiles. Monk checks them and deploys them.

​

What your coding agent can do

Your coding agent is a separate program with its own permissions. Depending on its settings, it can read files, edit code and run shell commands, including the monk CLI, without going through Monk’s tools or Monk’s approvals. Monk can’t limit that. Review your agent’s permission settings, and treat its approval prompts as seriously as Monk’s. Your coding agent also reads your source code to configure the project. Its provider’s terms cover that code.

​

The local dashboard

The local dashboard and Monk’s MCP endpoint listen only on your computer’s loopback address. Approvals, credential forms and certificate forms are only accepted from the dashboard session that monk-agent opened in your browser.

​

Related