Skip to main content

​
What It Does

Monk implements security at two critical levels:
  1. Agentic Security - Makes Monk itself safe to use as an AI agent
  2. Runtime Security - Protects your deployed applications and infrastructure
Both are built-in by default. No security configuration required.

​
Agentic Security: Making AI Safe

Monk is an autonomous AI agent with significant privileges - it can provision infrastructure, modify configurations, and manage your production systems. This requires robust safety mechanisms beyond typical AI applications.

​
Secrets Never Exposed to LLM

The problem: Traditional AI coding agents can accidentally expose secrets in prompts, logs, or generated code. Monk’s approach:
  • Secrets are never passed to the LLM
  • Secret values are never generated by the LLM
  • Secrets are handled by deterministic tooling, not AI inference
  • LLM only knows that a secret exists, never its value
Example: 
Wrong (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

Your credentials never travel to Monk servers:
  • All secrets stored locally (your machine) and on your infrastructure (your cloud)
  • Encrypted at rest using your cloud provider’s KMS
  • Bring Your Own KMS (BYO-KMS) - Monk uses your AWS KMS, GCP KMS, Azure Key Vault
  • Envelope encryption with key rotation after each read
  • Secrets never transmitted to monk.io infrastructure
Where secrets are stored:
  1. Development: Encrypted on your local machine
  2. Production: Encrypted in your cloud KMS (AWS KMS, GCP KMS, etc.)
  3. Never: Monk servers
This is part of the BYOI (Bring Your Own Infrastructure) model - everything runs on your infrastructure, including secret management.

​
Destructive Actions Require Approval

The problem: An AI agent making a mistake could delete production infrastructure. Monk’s approach:
  • Destructive actions are enforced by tooling, not AI choice
  • When AI calls a tool to delete resources, user is notified automatically
  • User must explicitly approve before action proceeds
  • Approval is processed by tooling, not LLM (AI can’t be manipulated to bypass)
  • AI can explain impact, but cannot proceed without user approval
Examples of protected actions:
  • Deleting infrastructure resources
  • Removing databases or storage
  • Tearing down production environments
  • Modifying security groups to reduce access
User experience: 
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 Understanding

Unlike simple coding agents, Monk understands the blast radius of changes: What Monk knows:
  • Which resources depend on which other resources
  • Impact of deleting a database (all services using it will fail)
  • Consequences of changing a security group (which services affected)
  • Effect of modifying a domain (which users experience downtime)
Traditional AI agents don’t have this context and can’t assess impact accurately.

​
Restricted Capabilities

Monk operates with carefully designed constraints: What Monk CAN do:
  • Generate and edit Dockerfiles, Monk configurations
  • Provision cloud resources via cloud provider APIs
  • Configure services using 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
  • Edit your application source code (only generated configs/Dockerfiles)
  • Bypass approval requirements for destructive actions

​
Deterministic Validation

Every LLM response is validated before execution:
  1. LLM generates a plan and tool calls
  2. Deterministic code validates the plan before execution
  3. Validation checks: correct parameters, safe operations, valid resource types
  4. Only after validation do actions execute
This prevents:
  • Malformed API calls
  • Invalid resource configurations
  • Unintended side effects
  • AI “hallucinations” causing infrastructure issues

​
Runtime Security: Protecting Your Applications

Once your application is deployed, Monk implements comprehensive runtime security.

​
Secret Storage & Management

Same principles as agentic security:
  • Secrets encrypted at rest in your cloud KMS
  • Envelope encryption with automatic key rotation
  • Secrets injected into containers at runtime (never in images)
  • Never logged or exposed in configurations
See Configuration & Wiring for how secrets are managed throughout your application.

​
Encrypted Networking & Segmentation

Automatic encryption:
  • All service-to-service communication encrypted by default
  • Overlay network spans all infrastructure (see Networking)
  • No manual VPN or WireGuard setup required
Automatic segmentation:
  • Network traffic between workloads automatically segmented
  • Services can only communicate if explicitly defined in connection graph
  • Lateral movement prevented by default

​
VM & Access Control

Every VM locked down:
  • No SSH access - VMs don’t expose SSH ports
  • Management via secure orchestrator APIs only
  • State-of-the-art encryption and authentication for management APIs
How you manage infrastructure:
  • Not by SSH into machines
  • Via Monk’s orchestrator API from your IDE
  • All management actions authenticated and encrypted

​
Automatic Firewall Management

Only desired ports open:
  • Public-facing services: only application ports (e.g., 80, 443)
  • Internal services: no public ports
  • Inter-service communication: only on private network
  • Everything else blocked by default
Dynamic updates:
  • Firewall rules update automatically as services scale
  • New instances get correct rules immediately
  • Removed instances have rules cleaned up

​
Container Security Best Practices

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

​
Automatic IP Whitelisting

When connecting to external resources, Monk manages IP whitelisting automatically: Example: MongoDB Atlas
  1. Your container needs to connect to MongoDB Atlas
  2. Monk knows the VM’s IP address
  3. Monk calls MongoDB Atlas API to whitelist that specific IP
  4. Only your container can connect, not arbitrary internet traffic
  5. When container moves to different VM, Monk updates whitelist automatically
Same for:
  • Redis Cloud
  • Managed databases
  • External APIs with IP restrictions
  • Any service that supports IP whitelisting

​
Airgapped & Enclosed Deployment

Enclosed VPC:
  • Manual setup required
  • Can run entirely within your VPC
  • No internet access required (except for external APIs your app needs)
  • Control plane and agents fully hosted on your infrastructure
Airgapped on-premises:
  • Manual setup required
  • Can run completely disconnected from internet
  • All management via local network
Contact us for guidance on airgapped deployments.

​
Coming Soon

Ingress with ModSecurity WAF COMING SOON Monk’s orchestrator includes ModSecurity WAF (Web Application Firewall) pre-installed. Agent management coming soon:
  • Automatic WAF protection against OWASP Top 10 attacks
  • SQL injection prevention
  • XSS protection
  • DDoS mitigation at application layer
  • Zero configuration required

​
What Makes This Different

Traditional AI agent security risks:
  • Secrets exposed in LLM prompts and logs
  • No approval mechanism for destructive actions
  • Can execute arbitrary commands
  • No blast radius understanding
  • Credentials sent to AI provider servers
Traditional runtime security requires:
  • Manual firewall rule configuration
  • Setting up VPNs for service communication
  • Configuring secret management tools (Vault, AWS Secrets Manager)
  • Managing SSH keys for server access
  • Manual IP whitelisting in external services
  • Writing security group rules for each service
  • Implementing network segmentation manually
With Monk: Agentic safety built into tooling. Runtime security configured automatically based on your application’s needs.

​
Key Capabilities

​
Agentic Security

  • Secrets never exposed to LLM - Handled by deterministic tooling
  • Secrets never leave your infra - BYO-KMS with envelope encryption
  • Destructive actions require approval - Enforced by tooling, not AI
  • Blast radius awareness - Understands impact of changes
  • Restricted capabilities - Can’t execute arbitrary commands or edit source code
  • Deterministic validation - Every AI response validated before execution

​
Runtime Security

  • Encrypted networking - All service communication encrypted by default
  • Automatic segmentation - Services isolated, lateral movement prevented
  • No SSH access - VMs managed via secure orchestrator APIs
  • Automatic firewalls - Only necessary ports open
  • Container best practices - Non-root, minimal images, security patches
  • Automatic IP whitelisting - External services whitelisted dynamically
  • BYO-KMS secret storage - Your cloud KMS, envelope encryption, key rotation
  • Enclosed VPC deployment - Can run entirely within your network
  • Airgapped support - On-premises, disconnected deployment possible