Bud MCP Foundry / Security & compliance

Security is foundational, not an afterthought.

Authentication is enforced by default on every API, protocol, and administrative endpoint. Administrative surfaces are disabled unless explicitly enabled. Defense-in-depth controls apply at every layer of the stack.

Overview

Defense-in-depth across four layers of the stack.

Below is the complete security specification across authentication, data protection, input validation, and operational security, followed by the compliance framework mapping to SOC 2, ISO 27001:2022, OWASP Top 10, and NIST CSF.

The final section covers the four supported deployment topologies and the infrastructure-as-code and supply-chain integrity controls that back them.

Authentication & identity

JWT, Argon2id, SSO, and token scoping.

The primary authentication method for API and protocol access is JWT bearer tokens. The platform supports nine signing algorithms across three cryptographic families, covering symmetric shared secrets and asymmetric key pairs.

FamilyAlgorithmsKey type

HMACHS256, HS384, HS512Symmetric shared secret

RSARS256, RS384, RS512Asymmetric RSA key pair

ECDSAES256, ES384, ES512Asymmetric elliptic curve key pair

Email & password

Passwords are hashed using Argon2id, the OWASP-recommended memory-hard algorithm, with configurable time cost, memory cost, and parallelism parameters. Account lockout engages after a configurable number of failed attempts. Every authentication event records IP address and user-agent metadata for forensic analysis.

Single sign-on & federation

Integrates through OAuth 2.0 and OpenID Connect. Supported providers: Google, Microsoft Entra ID (Azure AD), Okta, Keycloak, GitHub. PKCE with S256 and plain methods for Authorization Code flows. Cryptographic state tokens and nonces prevent CSRF and replay. Dynamic Client Registration per RFC 7591 with issuer allowlisting. OAuth metadata discovery per RFC 8414.

Token management

Only SHA-256 hashes of issued tokens are persisted. Raw token value is presented to the user exactly once at issuance
Token revocations enforced at the gateway layer before request processing begins
Every token-authenticated request records HTTP method, endpoint, client IP, user-agent, response latency, and block reason
Asymmetric key paths validated on startup; PEM material read securely

Asymmetric key material

Tokens issued with configurable expiration, issuer, and audience claims. Each token carries a unique jti (JWT ID). SSO client secrets and registration tokens encrypted with Fernet symmetric encryption before storage. Decryption only on demand during active authentication flows.

Data protection

No plaintext credentials, tokens, or passwords anywhere.

All sensitive data stored in the database is encrypted before persistence. The schema refuses plaintext secrets, and the platform's startup security validation refuses to boot if plaintext is detected.

Data typeEncryption methodKey derivation

Tool & resource credentialsAES-256-GCMArgon2id-derived 32-byte key

OAuth client secretsFernet (AES-128-CBC + HMAC-SHA256)Argon2id from operator-configured passphrase

SSO registration secretsFernetSame as OAuth secrets

User passwordsArgon2id hashN/A (one-way hash)

API token valuesSHA-256 hashN/A (one-way hash)

✓

Zero plaintext persistence

No plaintext credentials, tokens, or passwords are stored in the database. This is enforced at the schema level and verified at startup by the security validation system. The platform will refuse to start if it detects plaintext secrets in persistent storage.

Encryption in transit

TLS/HTTPS with built-in certificate generation tooling for development and standard certificate integration for production
HSTS headers emitted with configurable max-age and includeSubDomains directives
Secure WebSocket (WSS) for bidirectional MCP communication
Outbound TLS enforced by default for connections to upstream MCP servers

Encryption at rest

AES-256-GCM for tool and resource credentials, with Argon2id-derived keys
Fernet symmetric encryption for OAuth and SSO secrets
Argon2id for user passwords (memory-hard, OWASP-recommended)
SHA-256 hashes for API token values, with raw token shown exactly once at issuance

Input validation

Centralized validation enforced at the schema level.

All user-supplied input passes through a centralized validation layer before any business logic runs. This prevents injection, deserialization attacks, and resource-exhaustion vectors from ever reaching a handler.

Injection detection

Configurable regex patterns detect dangerous HTML tags, JavaScript protocol handlers, event handler attributes, and template injection patterns.

JSON depth limiting

Nested JSON payloads validated against configurable maximum depth to prevent resource exhaustion and deserialization attacks.

URL scheme allowlisting

Only http, https, ws, and wss schemes permitted. javascript:, data:, and vbscript: rejected.

Length enforcement

Field-specific limits: names 255 chars, descriptions 8 KB, content payloads 1 MB. Applied before any downstream processing.

Safe character sets

Identifiers, tool names, and URIs validated against allowlisted character patterns to prevent encoding-based bypasses.

MIME type validation

Content types validated against a configurable allowlist. Unknown or unsafe MIME types rejected at the edge.

Operational security

Supply chain, observability, and continuous verification.

Operational controls cover the full lifecycle from startup to runtime to release, with automated verification at each stage.

Startup security validation

Refuses to start if weak defaults are detected in production. Validates secret rotation posture, asymmetric key paths, TLS configuration, and database encryption at boot.

Structured audit logging

Automatic sensitive-data masking. Every privilege decision, admin action, and permission change recorded with full request context for forensic analysis and compliance reporting.

Distributed tracing

OpenTelemetry tracing with W3C Trace Context propagation. Export to OTLP (gRPC/HTTP), Jaeger, Zipkin, or console.

Prometheus metrics

Every HTTP endpoint instrumented. Exposed /metrics endpoint. Per-tool, per-gateway, per-server, per-agent, per-skill counters.

LogFire agent trails

Dedicated AI agent activity logging with per-agent interaction trails. Captures tool invocations, skill executions, prompt renderings, and A2A communications.

Supply chain integrity

Automated vulnerability scanning in CI/CD. Software Bill of Materials (SBOM) generation for every release. Container image signing and supply chain integrity verification.

Appendix A

Compliance standards mapping.

Bud MCP Foundry's security controls map directly to four major compliance frameworks. The matrix below aligns each control area to SOC 2 Trust Services Criteria, ISO 27001:2022 Annex A controls, OWASP Top 10 (2021), and NIST Cybersecurity Framework 2.0 categories.

Control areaSOC 2 TSCISO 27001:2022OWASP Top 10NIST CSF

AuthenticationCC6.1, CC6.2A.9.2, A.9.4A07 Identification & Auth FailuresPR.AC-1, PR.AC-7

Authorization (RBAC)CC6.1, CC6.3A.9.1, A.9.2A01 Broken Access ControlPR.AC-4

Encryption in transitCC6.7A.10.1, A.13.1A02 Cryptographic FailuresPR.DS-2

Encryption at restCC6.7A.10.1, A.8.2A02 Cryptographic FailuresPR.DS-1

Input validationCC6.6A.14.2A03 InjectionPR.DS-5

Security headersCC6.6A.14.1A05 Security MisconfigurationPR.IP-1

Rate limitingCC6.6, CC7.2A.12.1A04 Insecure DesignPR.DS-4

Secrets managementCC6.1, CC6.7A.10.1A02 Cryptographic FailuresPR.DS-1

Container hardeningCC6.6A.12.5, A.12.6A06 Vulnerable ComponentsPR.IP-1

Supply chain securityCC8.1A.14.2A06 Vulnerable ComponentsPR.IP-2

SBOM & image signingCC8.1A.14.2A08 Software & Data IntegrityPR.DS-6

Logging & auditCC7.1, CC7.2A.12.4A09 Logging & Monitoring FailuresDE.AE-3, DE.CM-1

Incident responseCC7.3, CC7.4A.16.1A09 Logging & Monitoring FailuresRS.RP-1

Security pluginsCC6.6, CC7.2A.14.1A04 Insecure DesignPR.IP-1, DE.CM-4

Formal certifications are obtained on a per-deployment and per-tenant basis. SOC 2 Type II certification is in progress on the standard enterprise timeline.

Appendix B

Four deployment topologies.

Bud MCP Foundry supports four deployment topologies, chosen based on scale, regulatory constraints, and sovereignty requirements.

Single-cluster, single-instance

When to use: Development and small deployments with fewer than 10 capabilities.

Not recommended for production. Useful for local development, proof-of-concept demonstrations, and internal evaluation environments.

Single-cluster, multi-replica

When to use: Mid-sized deployments within a single regulatory zone.

Horizontal scaling within one zone. Suitable for teams that need production characteristics without multi-zone complexity.

Multi-zone federation

When to use: Enterprises with multiple regulatory zones or air-gap requirements.

Recommended for banks, healthcare, and government deployments. Each zone independently auditable. Bifrost federates the capability surface across zones.

Sovereign multi-region

When to use: National-scale sovereign AI deployments.

Integrates with sovereign compute providers. Air-gapped deployment support. Designed for data-sovereignty mandates and classified workloads.

Container, cloud, and IaC support

Docker and Podman container images on GitHub Container Registry
Kubernetes deployment with Helm charts
IBM Cloud Code Engine, AWS, Azure, Google Cloud Run
Terraform modules for AWS, Azure, GCP
Ansible playbooks for on-premises and bare-metal
CI/CD pipelines with GitHub Actions
Security scanning and SBOM generation in the release pipeline
GitOps workflows with ArgoCD-compatible manifests
Blue-green deployment support and zero-downtime update procedures

Continue the evaluation.

Review the platform architecture, the full integrations catalog, or industry-specific deployment patterns.

Platform architecture Integrations catalog Industry solutions Back to overview