Security & Compliance

Both MCP Fortress and PAT Fortress are built on the same security-first architecture. Credentials are never logged, never returned in API responses, and only enter Serverless Function memory after all policy checks pass.

Three Tiers of Credential Trust

Choose how much you trust Kestra Labs with your keys. All three tiers apply to both MCP Fortress and PAT Fortress.

SOHO

Managed Vault

"Giving your house key to a trusted neighbor"

MCP Fortress
Kestra Labs holds encrypted SaaS credentials (API keys, OAuth tokens) in Key Management-encrypted vault. Decrypted on each request.
PAT Fortress
Kestra Labs holds encrypted Claude PATs in Key Management-encrypted vault. Decrypted on each request.
Setup Time
~5 minutes
Credential Flow
Managed Database → Key Management decrypt → token in memory → used → erased
Bank

Safety Deposit Box

"Your key + our key required"

MCP Fortress
Customer maintains their own Key Management key. Kestra Labs retrieves encrypted SaaS credential but only customer's Key Management key can decrypt.
PAT Fortress
Same: customer's Key Management key required to decrypt Claude PAT into memory.
Setup Time
~30 minutes
Credential Flow
Managed Database → Key Management decrypt (customer key via grant) → token in memory → used → erased
Zero Trust

No Keys Stored

"Credentials never leave your building"

MCP Fortress
No SaaS credentials stored. Identity via Entra ID, device posture via MDM provider, org Key Management key retrieved per session.
PAT Fortress
No Claude PATs stored. Same identity + device flow, session-scoped key lifecycle.
Setup Time
2-4 hours
Credential Flow
Entra ID validated → device posture checked → org Key Management key into memory → credential decrypted → used → explicitly zeroed

Security Requirements: Non-Negotiable

1

Credentials NEVER logged. Not in Monitoring, not in errors, not in audit. Serverless Function memory only.

2

Credentials NEVER returned in API responses. Admin API shows metadata only.

3

Key Management key policy restricts decrypt to the policy engine execution role only. No human user can decrypt.

4

PAT Fortress: Claude PAT is NEVER exposed to the end user. They authenticate with org API key + Entra ID. The real Claude PAT is internal.

5

All data in transit: TLS 1.2+. Redis: in-transit encryption. Managed Database: at-rest encryption.

6

API keys hashed (SHA-256) before storage. Shown once at creation, never again.

7

Zero Trust credential lifecycle: key enters memory → used → explicitly zeroed. No disk, no swap.

8

Device posture re-validated every 15 minutes (cache TTL). Compromised device = instant revocation.

9

PAT Fortress: full request/response logging stored in encrypted object storage with server-side encryption. Access restricted to audit roles only.

10

Private Network Flow Logs and CloudTrail enabled for all resources.

Compliance Frameworks

SOC 2 Type II is a Trust Services Criteria framework demonstrating controls over security, availability, and integrity of systems.

Key Controls

CC6.1: Logical Access Controls
Role-based access control (RBAC) restricts who can access credentials. Key Management key policy restricts decrypt to the policy engine execution role only.
CC6.2: User Access Reviews
SCIM integration with Entra ID for automated user provisioning and quarterly access reviews.
CC8.1: Change Management
Immutable Change Log tracks all credential storage, policy, and device posture configuration changes with before/after diffs.
A1.2: System Availability
99.9% uptime SLA with multi-region failover and redundant Key Management key replicas.
I1.1: System Integrity
Credentials verified via HMAC on every use. Managed Database point-in-time recovery enabled.

ISO 27001:2022 is the international standard for information security management systems (ISMS).

Key Controls

A.5.1: Policies for Information Security
Documented security policies covering credential handling, authentication, and device posture requirements.
A.6.1: Organization of Information Security
Cross-functional security team with defined roles and responsibilities for both MCP Fortress and PAT Fortress.
A.7: Human Resource Security
Background checks, onboarding/offboarding procedures, and security awareness training for all employees.
A.9.2: User Access Management
Multi-factor authentication (MFA) required for all console access. Entra ID federation enforces conditional access policies.
A.10.1: Cryptography
AES-256 encryption at rest. TLS 1.2+ in transit. Key rotation every 90 days. Zero Trust tier uses customer-managed keys.

NIST 800-53 and Cybersecurity Framework 2.0 provide security controls and continuous monitoring guidance.

Key Controls

AC-2: Account Management
Automated user lifecycle management via SCIM. Inactive accounts disabled after 90 days.
SC-7: Boundary Protection
Private Network isolation with security groups. Serverless Function execution role restricted to decrypt only. Network ACLs enforce least privilege.
AU-2: Audit Events
All API calls logged to CloudTrail. PAT Fortress logs full request/response to encrypted object storage for audit trail.
IA-2: Authentication
Entra ID/OIDC integration. MFA enforced. Device posture checks every 15 minutes. Zero Trust tier requires all three.
SA-3: System Development Life Cycle
Infrastructure as code (Terraform) stored in Git with signed commits. Automated security scanning in CI/CD.

PCI DSS 4.0 applies when handling payment card data or integrating with payment systems.

Key Controls

1.1: Network Architecture
Private Network-isolated serverless functions. No direct internet access without approved security controls.
2.1: Default Passwords
No default credentials. All accounts provisioned via Entra ID with MFA enforced from day one.
3.2: Encryption at Rest
AES-256 encryption for all data at rest. Key Management-managed keys with automated rotation.
4.1: Encryption in Transit
TLS 1.2 minimum for all connections. Certificate pinning in PAT Fortress SDKs.
10.2: Logging and Monitoring
All access logged and monitored. Automated alerting on suspicious patterns. Audit logs retained for 3 years.

GDPR applies to any processing of personal data of EU residents, including authentication data and audit logs.

Key Controls

Article 5: Data Protection Principles
Legitimate interest basis for credential storage. Data minimization: only store what is necessary. Integrity and confidentiality via encryption.
Article 13-14: Transparency
Privacy policy and Data Processing Agreement available. Transparent about credential handling in all three tiers.
Article 32: Security Measures
Encryption at rest and in transit. Regular security assessments. Incident response plan with 72-hour breach notification.
Article 35: Data Protection Impact Assessment
DPIA completed for Zero Trust tier. Published DPIA available upon request.
Article 28: Data Processing Agreement
Standard DPA available for all organizations. EU Standard Contractual Clauses included for data transfers.

HIPAA applies to healthcare providers and covered entities handling Protected Health Information (PHI).

Key Controls

45 CFR 164.308(a)(1): Security Management Process
Documented security policies, risk assessment, and workforce security procedures.
45 CFR 164.312(a)(2): Access Controls
Unique user IDs for all access. Role-based access control. Automatic logoff after 15 minutes of inactivity.
45 CFR 164.312(a)(2)(ii): Encryption and Decryption
AES-256 encryption for all PHI at rest. TLS 1.2+ for all data in transit.
45 CFR 164.312(b): Audit Controls
Comprehensive audit logs of all PHI access. Tamper-evident logging with immutable storage in encrypted object storage.
45 CFR 164.404: Notification of Breach
Breach detection and incident response procedures. Notification plan in place within 60 days.

DIY vs Kestra Labs

What it takes to build this yourself vs. using our managed platform.

Capability DIY Kestra Labs
Credential Storage Build Key Management integration, key rotation, vault Managed vault with three trust tiers
Identity & SSO Integrate SSO provider yourself Built-in SAML/OIDC federation
Device Posture Build MDM provider integration Zero Trust tier includes device checks
Policy Engine Build RBAC from scratch Visual Policy Radar, deny-by-default
Audit Logging Build structured logging pipeline Every request logged, exportable evidence
Claude API Governance Nothing: raw API keys shared with developers PAT Fortress: model allowlists, spend caps, full audit
PII Redaction Build regex/NLP pipeline Configurable per-role per-connector
Compliance Evidence Manual spreadsheets for auditors One-click SOC 2/ISO evidence export
Time to Production 3-6 months 5 minutes (SOHO)

What Your Auditor Will Ask

Click each question to see how a DIY approach compares to Kestra Labs, straight from a SOC 2 Type II auditor's playbook.

How are SaaS credentials stored? +
DIY Approach
  • Build your own Key Management integration and key rotation
  • Secrets stored in config files, environment variables, or a vault you maintain
  • No tiered trust model, one approach for all customers
  • You write the encryption/decryption code and hope the implementation is correct
Kestra Labs
  • SOHO: Managed vault with AES-256 encryption, decrypted only in serverless memory per request, then erased
  • Bank: Customer holds their own Key Management key, credentials can only be decrypted with their key
  • Zero Trust: No credentials stored at all, retrieved from customer's Key Management per request, validated through SSO + device posture, then zeroed from memory
How are Claude API keys protected? +
DIY Approach
  • Raw API keys shared directly with developers in .env files or secrets managers
  • No visibility into which developer called which model with what data
  • No spend governance, any developer can run any model, any volume
  • Revoking access means rotating the key for everyone
Kestra Labs
  • Developers never see the real Claude PAT, they authenticate with their org API key + SSO credentials
  • Same three-tier vault model (SOHO/Bank/Zero Trust) protects Claude keys
  • Every API call logged with full request/response, user, timestamp, and device
  • Model allowlists and spend caps enforce governance per PAT key
Who can access credentials? +
DIY Approach
  • Whoever has access to your vault, config files, or deployment pipeline
  • Hard to prove which human accessed which credential and when
  • DevOps team often has blanket access to all secrets
  • No automated proof of least-privilege enforcement
Kestra Labs
  • Key Management Policy: Only the serverless execution role can decrypt, no human user, including Kestra Labs employees
  • RBAC: Only users with the right role can request a credential be used
  • Conditional Access: MFA required, device compliance checks block non-compliant devices
  • Full audit trail of every credential access event
How is user access controlled? +
DIY Approach
  • Build SSO integration from scratch (SAML/OIDC)
  • Write your own RBAC system and maintain permission matrices
  • No visual policy editor, roles defined in code or config
  • Default-allow is the common pattern unless you explicitly deny
Kestra Labs
  • SSO Federation: SAML/OIDC integration with your identity provider, out of the box
  • MFA: Required for all console users
  • Visual Policy Radar: Fine-grained roles with an intuitive GUI, toggle switches, not config files
  • Deny-by-Default: Nothing is permitted unless explicitly granted
What happens when a device is compromised? +
DIY Approach
  • Build MDM integrations yourself across multiple providers
  • No automatic revocation, you manually disable accounts when notified
  • Gap between device compromise and credential revocation is hours or days
  • No continuous posture validation, checked once at login, never again
Kestra Labs
  • 4 MDM Providers: Intune, Jamf, Workspace ONE, and Google Endpoint, all built-in
  • 15-Minute Cache TTL: Device posture is re-evaluated every 15 minutes
  • Instant Revocation: Non-compliant device = immediate access block, no credentials accessible
  • Zero Trust: Device posture is mandatory, no compliant device, no access
Can you prove what Claude did with customer data? +
DIY Approach
  • Build your own logging pipeline for API requests/responses
  • Hope developers don't bypass logging in their implementations
  • No immutability guarantee, logs can be edited or deleted
  • Manual spreadsheets to compile evidence for auditors
Kestra Labs
  • Full Logging: Every Claude API call logged: request body, response, user, device, timestamp
  • Immutable: Logs cannot be modified or deleted, encrypted object storage with restricted access
  • Exportable: One-click export in CSV/JSON for compliance teams
  • PII Redaction: Sensitive data redacted per role and connector before logging
How are changes tracked? +
DIY Approach
  • Git history is your audit trail, if people commit changes at all
  • No before/after diffs for config changes outside of code
  • No multi-person approval for critical changes
  • Compiling a change log for auditors means manual git log parsing
Kestra Labs
  • Immutable Change Log: Every change to credentials, policies, device rules, or users is recorded
  • Before/After Diffs: Old and new values shown side-by-side
  • User Attribution: Every change tied to a specific user and timestamp
  • Approval Workflows: Critical changes can require multi-person sign-off

Ready to Secure Your AI?

GET STARTED CONTACT SALES