Customer Security Guide

Audience: Security engineers, compliance officers, platform administrators Updated: 2026

Control Core is built with enterprise-grade security and compliance in mind. This guide covers security features, compliance posture, deployment hardening, and operational best practices for running Control Core in your infrastructure.

AI and Agent API Protection

Control Core enforces a unified authorization model across all API types, including AI-native protocols:

• Unified controls across REST, GraphQL, MCP, and A2A APIs — one control model, consistent enforcement
• End-user identity continuity — require verified end-user identity on agent-originated tool calls, preventing privilege escalation through AI intermediaries
• Trusted server controls — restrict AI agent tooling access to approved MCP servers
• Input risk screening — detect and block suspicious tool argument patterns before access is granted
• Agent-specific guardrails — apply stricter usage tiers and quotas for machine identities

Data Protection

Access Control

• Enterprise SSO: Auth0, Okta, Azure AD, and OIDC-compatible providers
• Multi-factor authentication: Required for all administrative access
• Role-based admin access: Granular permissions and role management within the Control Plane
• Session management: Configurable session timeouts; secure cookie settings

Compliance Posture

SOC2 Type II

Control Core is designed to meet SOC2 Type II compliance requirements across all five trust service categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy.

Data Privacy

• GDPR compliant: Right to deletion, data portability, and consent management
• CCPA compliant: California Consumer Privacy Act requirements
• Data minimisation: Collects only necessary data for service operation
• Consent management: Granular consent tracking with full audit trail

Container Security

Control Core images are hardened for enterprise deployment and comply with Kubernetes Pod Security Standards (restricted profile).

Image hardening

Helm security context

The Helm chart ships with a global.securityContext block that enforces the restricted Pod Security Standard by default:

global:
  securityContext:
    runAsNonRoot: true
    readOnlyRootFilesystem: true
    allowPrivilegeEscalation: false
    capabilities:
      drop:
        - ALL

Image registry

All Helm values use the controlcoreio/<image>:<tag> convention. To pull from a private registry, set global.imageRegistry:

global:
  imageRegistry: "your-registry.example.com"

Secrets management

Never store API keys or passwords as literal values in Helm values files. Use Kubernetes Secrets with secretKeyRef, or integrate an external secrets operator (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault):

global:
  secrets:
    sandboxApiKeySecretRef: "controlcore-sandbox-key"
    productionApiKeySecretRef: "controlcore-production-key"

Troubleshooting: If pods fail with CrashLoopBackOff after enabling readOnlyRootFilesystem, ensure writable emptyDir volumes are mounted for /tmp and any application cache directories. Check kubectl describe pod for permission errors.

Deployment Security

Network requirements

Minimum recommended firewall configuration:

# Exposed (external or DMZ)
ports:
  - 443/tcp   # HTTPS to Control Plane UI + API (use TLS termination)
  - 8080/tcp  # Bouncer (protected resources — restrict to trusted clients)

# Internal only (never expose to internet)
  - 5432/tcp  # PostgreSQL (db ↔ api only)
  - 6379/tcp  # Redis (api ↔ redis only)
  - 7000/tcp  # Policy Bridge / Controls sync (api ↔ bouncer only)

OS hardening (Ubuntu/Debian)

# Enable firewall — deny all inbound by default
sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp    # SSH: restrict to management CIDR in production
sudo ufw allow 443/tcp   # HTTPS
sudo ufw allow 8080/tcp  # Bouncer: scope to trusted load balancer IP

# Apply security updates
sudo apt update && sudo apt upgrade -y

System requirements (production)

AWS-specific security

• VPC: Use private subnets for all Control Core containers; place ALB in public subnet
• Security Groups: Restrict inbound to necessary ports from known CIDRs only
• IAM Roles: Use least-privilege IAM for any AWS service the stack accesses
• CloudTrail: Enable in the region of deployment

Azure-specific security

• Virtual Network: Use private endpoints; place app subnet in private tier
• Network Security Groups: Restrict network access per security group rule above
• Azure AD Integration: Use Azure AD as the SSO provider
• Azure Monitor: Enable comprehensive logging

GCP-specific security

• VPC Network: Use private Google access
• Firewall Rules: Restrict per network requirements above
• IAM Policies: Use least-privilege service accounts
• Cloud Logging: Enable audit logging

Security Best Practices

Access management

1. Use strong passwords with complexity requirements (or SSO — recommended for production)
2. Require MFA for all administrative accounts
3. Conduct regular access reviews; revoke unused service accounts promptly
4. Apply least-privilege: grant the minimum necessary permissions to every role

Data protection

1. Encrypt storage volumes (filesystem or cloud-provider encrypted volumes)
2. Automate daily database backups to encrypted, separate storage
3. Apply data classification to control what attributes PIPs can expose to controls

Monitoring and logging

1. Enable audit logging — all control decisions generate immutable audit records by default
2. Forward audit logs and SIEM events to your log management system (see Actions Reference)
3. Configure alert routing for high-severity deny events
4. Conduct regular log reviews; maintain a defined incident response runbook

Security Monitoring

Control Core provides built-in monitoring capabilities:

• Real-time decision audit trail — every Allow/Deny/Mask decision logged with full context
• Anomalous Activity dashboard — security-relevant patterns flagged in the last 24 hours
• SIEM integration — forward events via siem_log post-decision actions
• Compliance dashboard — real-time compliance status per control and resource

Incident Response

Customer procedures

1. Identify — monitor audit logs and anomaly alerts for unusual decision patterns
2. Contain — use Bouncer SECURITY_POSTURE=deny-all to lock a resource immediately while investigating
3. Document — export audit logs for the incident window; preserve evidence
4. Recover — restore from backup or rollback controls to last known good version
5. Review — conduct post-incident review and update controls and runbooks accordingly

Emergency access

For emergency access override, configure break_glass_notify actions on relevant controls — see Actions Reference.

Support and Contact

Related guides

• Security Overview
• Control & Policy Hardening
• Cryptographic Workload Identity
• Observability & Trust
• Actions Reference — SIEM & notifications