Skip to main content

​
What It Does

Monk handles security at two levels:
  1. Agentic Security — keeps the AI agent itself safe to use
  2. Runtime Security — protects your deployed apps and infrastructure
Both are on by default. You don’t configure anything.

​
Agentic Security

Monk is an autonomous agent with real privileges. It provisions infrastructure, changes configs, and manages production. That demands safety mechanisms you won’t find in typical AI tools.

​
Secrets Never Reach the LLM

Credentials are encrypted at rest in your IDE’s secret storage and on your Monk cluster using your cloud provider’s KMS. They are never sent to Monk servers and never exposed to the LLM. How it works:
  • Secrets are handled by deterministic tooling, not AI inference
  • The LLM only knows a secret exists — it never sees the value
  • Secret values are never generated by the LLM
Typical AI agent:
  LLM sees: DATABASE_URL=postgresql://user:password123@host:5432/db

Monk:
  LLM sees: DATABASE_URL=[SECRET:postgres_connection]
  Tooling handles: postgresql://user:password123@host:5432/db

​
Secrets Never Leave Your Infrastructure

Where secrets live:
  • Workspace/user scope — your IDE’s secret storage, encrypted at rest by OS toolchain (macOS Keychain, Windows Credential Manager, Linux Secret Service)
  • Team scope — on your org cluster, envelope-encrypted with your cloud provider’s KMS
  • Never — Monk servers
BYO-KMS: Team secrets use envelope encryption with your provider’s key management service — AWS KMS, GCP Cloud KMS, Azure Key Vault, or DigitalOcean managed encryption keys. Each read uses a fresh data key. Rotation is automatic. This is part of the BYOI (Bring Your Own Infrastructure) model. Everything runs on your infrastructure, including secret management.

​
Destructive Actions Require Approval

Monk can’t silently destroy things. Destructive actions are gated by tooling, not by AI judgment. When Monk needs to delete resources, it tells you exactly what’s affected. You approve or reject. The approval flow is handled by tooling — the AI can’t be manipulated to bypass it. Protected actions include:
  • Deleting infrastructure resources
  • Removing databases or storage
  • Tearing down production environments
  • Reducing security group access
Monk: To complete this task, I need to delete the staging environment.
      This includes:
      - 3 VMs (total cost: $45/month)
      - PostgreSQL database (last backup: 2 hours ago)
      - 50GB storage

    [YES] [NO]

[User must explicitly click [YES] - answer not processed by AI]

​
Blast Radius Awareness

Monk understands what depends on what. Before making changes, it knows:
  • Which services break if you delete a database
  • Which users see downtime if you change a domain
  • Which services are affected by a security group change
This isn’t guesswork. Monk tracks your resource graph and computes impact from it.

​
Restricted Capabilities

Monk operates within hard boundaries. What Monk CAN do:
  • Generate and edit Containerfiles, Monk configurations
  • Provision cloud resources via provider APIs
  • Configure services via orchestrator APIs
  • Read code in your open workspace
What Monk CANNOT do:
  • Execute arbitrary CLI commands on your machine
  • Make arbitrary API calls outside its tooling
  • Access files outside your open IDE workspace
  • Bypass approval requirements for destructive actions
Monk does not edit source code without your explicit approval. See Source Code Editing for how that works.

​
Deterministic Validation

Every LLM response is validated before execution:
  1. LLM generates a plan and tool calls
  2. Deterministic code validates the plan
  3. Validation checks parameters, operation safety, and resource types
  4. Only after validation do actions execute
This catches malformed API calls, invalid configs, and hallucinated operations before they touch anything.

​
Runtime Security

Once your app is deployed, Monk locks it down automatically.

​
Secret Storage and Management

Credentials are encrypted at rest in your IDE’s secret storage and on your Monk cluster using your cloud provider’s KMS. They are never sent to Monk servers and never exposed to the LLM. At runtime:
  • Secrets are injected into containers at runtime, never baked into images
  • Team secrets are environment-scoped — staging and production get separate values
  • Secrets are never logged or exposed in configurations
See Configuration & Wiring for how secrets flow through your application.

​
Encrypted Networking and Segmentation

All service-to-service communication is encrypted by default. Monk’s overlay network spans all your infrastructure — no manual VPN or WireGuard setup. Traffic is segmented automatically:
  • Services only communicate if your connection graph says they should
  • Lateral movement is prevented by default
  • See Networking for the full picture

​
VM and Access Control

VMs don’t expose SSH ports. You manage infrastructure through Monk’s orchestrator API from your IDE. All management actions are authenticated and encrypted.

​
Automatic Firewall Management

Only the ports you need are open:
  • Public-facing services expose application ports (80, 443)
  • Internal services have no public ports
  • Inter-service communication stays on the private network
  • Everything else is blocked
Firewall rules update automatically as services scale. New instances get correct rules immediately. Removed instances are cleaned up.

​
Container Security

When Monk generates Containerfiles (see Containerization), it follows security best practices:
  • Non-root users in containers
  • Minimal base images (Alpine, distroless)
  • No unnecessary packages
  • Multi-stage builds to minimize attack surface

​
Automatic IP Whitelisting

When your containers connect to external services, Monk handles IP whitelisting for you. Example: your container connects to MongoDB Atlas. Monk knows the VM’s IP, calls the Atlas API to whitelist it, and updates the whitelist automatically if the container moves. Same for Redis Cloud, managed databases, and any service that supports IP-based access control.

​
Airgapped and Enclosed Deployment

Enclosed VPC: Run entirely within your VPC with no internet access required (except for external APIs your app needs). Manual setup required. Airgapped on-premises: Run completely disconnected from the internet with all management over your local network. Manual setup required. See Getting Help for guidance on airgapped deployments.

​
Ingress WAF

Monk’s ingress controller includes ModSecurity WAF on all clusters by default. See Networking for details.

Networking

Encrypted overlay network, firewalls, and ingress configuration.

Configuration & Wiring

Secret management, injection, and environment wiring.