monkPermissions below the model
Organization roles govern the resources and operations a person can access. The agent’s tool calls are checked against that authority. Instructions can guide behavior; they cannot grant a permission.
You set the limits.
Monk enforces them.
Give your agent the ability to operate an application, with permissions, approvals and secret access enforced by the tooling underneath it.
Explore the runtime baselineYour coding agentProposed change
Monk’s control boundary
- Validate the operation
- Check your permissions
- Request required approval
Your infrastructureApply and record the authorized change
Authority you can inspect.
These controls belong to the system that executes the change. They keep working when the conversation ends or a different agent takes over.
A plan you can review
Review the proposed deployment, affected resources, warnings and estimated costs before provisioning. Protected actions wait for a decision in Monk’s dashboard. A chat message is not a dashboard approval.
Secrets with an explicit scope
Enter credentials in Monk’s local form. Tools refer to secret names while the vault handles values. Workloads and integrations declare the secrets they may read through permitted-secrets.
An environment boundary you choose
Production, staging and branch environments have their own configuration and access context. Capsules can use separate clusters or share capacity. Choose separate clusters when the boundary must include the infrastructure itself.
A record of the change
Tool actions and approval events are attributed to an actor and recorded in the organization’s activity trail. Inspect what was requested, how it was decided and whether the action completed.
Recovery with defined limits
The orchestrator recovers workloads within configured policies, retry budgets and available capacity. Watcher investigates incidents and proposes repairs. Those repairs need your approval.
Your cloud account stays yours. You choose the credentials, environment boundaries and access you give Monk.
The orchestrator’s
security baseline.
Controls for the infrastructure itself: how nodes communicate, how resources are exposed and how secrets reach their consumers.
- Encrypted cluster networking
Monk’s WireGuard overlay carries traffic between managed nodes. Declared connections give the orchestrator the information it needs to wire services across machines and clouds.
External SaaS connections use the provider’s own endpoints and transport.
- Explicit public exposure
Ingress and published ports determine which application endpoints are public. Internal dependencies communicate over the managed network; adding a database does not require a public application endpoint.
Review ingress, provider firewall rules and external service allowlists as part of the deployment.
- Encrypted secret storage
The local companion uses an OS keychain or encrypted vault. The orchestrator’s vault supports envelope encryption and KMS backends for AWS, Google Cloud and Azure, alongside its local backend.
The configured backend and scope determine where a secret is stored and which workloads receive it.
- Authenticated management
Cluster peers have cryptographic identities, and the management transport uses authenticated, encrypted connections. Organization authorization controls access to managed resources.
Personal accounts and organization scopes have different access models. Cloud credentials also retain their provider-side permissions.
- Validated operations
Tool inputs are checked against schemas. Deployment configuration is analyzed before execution, and protected operations use explicit approval flows.
Validation checks configuration and permissions; application testing remains part of your release process.
- Runtime secret permissions
Secrets are resolved by the runtime for authorized consumers. Explicit secret declarations constrain access by workload or entity, instead of giving every component a shared credential pool.
Application code still controls what it writes to logs or sends to other services.
Know where
your data goes.
Monk’s local companion, your coding-agent host and your cloud have different responsibilities.
Read the privacy policy- Repository & model context
- Your coding agent reads the workspace and calls Monk’s tools. Source and tool output supplied to that host are subject to its model provider and account settings.
- Credentials & secret values
- Use Monk’s local credential and secret forms. The vault supplies values to the operations that need them; the agent works with references. Keep secret values out of chat and application logs.
- Application & deployment state
- Your workloads and data run in the accounts you connect. Monk retains managed deployment state so later operations can refer to the running system.
- Account & activity
- Monk’s platform handles account, organization, billing and operational activity records. Review the privacy policy for the service’s data practices.
Before you connect production.
Can team instructions grant access?
No. Team instructions guide the agent’s choices. Organization permissions, provider credentials and tool approval checks determine what it can execute.
Does every action require a new approval?
No. Read operations and configured workload recovery can proceed within their existing authority. Deployment plans and protected changes use the relevant approval flow. Watcher’s proposed repairs require human approval.
Does every preview get a separate cluster?
Capsules support both new cluster capacity and an existing shared cluster. The plan determines which services, credentials and resources are separate or shared. Choose that boundary before deploying.
Is Monk SOC 2 certified?
Monk does not currently claim a security certification. Contact the security team for the current audit program, available evidence and your organization’s review requirements.
Talk through your requirements.
For architecture reviews or private vulnerability reports, contact security@monk.io. Include reproduction steps and impact when reporting a vulnerability.