> ## Documentation Index > Fetch the complete documentation index at: https://docs.monk.io/llms.txt > Use this file to discover all available pages before exploring further. # Security > How Monk handles credentials and secrets, what needs your approval, and where Monk's control ends 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](/getting-started/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](/concepts/watcher-and-recovery) [Obtaining credentials](/getting-started/obtaining-credentials) explains what each provider needs. You can see which credentials are stored, and delete them, at any time. ## Where secrets are stored | Scope | Where it lives | Who can use it | | - | - | - | | Workspace | The local vault on your computer | Deploys from this workspace | | Global | The local vault on your computer | All your workspaces on this computer | | Project, environment | The cluster's secret store | Deploys to that project or environment | | Account | The secret store on your personal clusters | You | | Organization | The secret store on the organization's clusters | Members with permission | 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](/guides/cicd) and [preview environments](/guides/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](/concepts/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 Adding and changing secrets Approvals, forms and the vault Roles and permissions What each provider needs This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.