🔌 MCP Fortress Setup

MCP Connectors are secure, credential-backed integrations to your SaaS tools. Configure them once in the Vault, then control who can use them via Policy Radar.

Credential Types by Tier

Adding a Connector

1. Navigate to Vault → Connectors in the admin dashboard.
2. Click Add Connector.
3. Select a SaaS tool from the catalog (Zendesk, Slack, GitHub, Jira, Salesforce, etc.).
4. Enter your credentials (API key, username/password, OAuth token, or app credentials).
5. Click Test Connection to validate. Kestra Labs makes a test API call to the SaaS tool.
6. If the test passes, click Save & Deploy. The connector is now ACTIVE.

Connector Lifecycle

Testing a Connector

After adding a connector, always run a test. Kestra Labs validates that:

• Credentials are correct and not expired
• The target SaaS API is reachable and responding
• Basic permissions are granted (e.g., read access for test calls)

Test results appear in seconds. If the test fails, check credentials and try again.

Connector Tools

Once a connector is active, Kestra Labs automatically exposes its available tools to Claude. For example, a Zendesk connector exposes:

• list_tickets(status, assignee)
• get_ticket(id)
• create_ticket(subject, description, priority)
• update_ticket(id, status, comment)

Which tools Claude can access is controlled by Policy Radar roles and conditional rules.

🔑 PAT Fortress Setup

PAT Fortress is a transparent proxy to the Claude Messages API. Your developers point their apps at pat.kestralabs.com instead of api.anthropic.com. Kestra Labs holds the real Claude PAT and enforces policies.

Adding a Claude PAT

1. Navigate to Vault → PAT Keys in the admin dashboard.
2. Click Add PAT Key.
3. Paste your Claude Personal Access Token. Copy it directly from Claude.ai's settings.
4. Configure controls:
   • Label: A friendly name (e.g., "Production PAT", "Dev PAT", "Research PAT")
   • Model Allowlist: Select which Claude models this PAT can access. For example, allow only claude-sonnet-4-5-20250929 and deny claude-opus-4-20250115 if desired. Leave blank to allow all models.
   • Max Tokens per Request: Hard limit on output tokens (e.g., 4000). Requests exceeding this are rejected.
   • Monthly Spend Cap: Budget limit in USD. When exceeded, requests are denied until the next month.
5. Click Save & Encrypt. PAT is encrypted and stored according to your tier.

PAT Lifecycle

How Developers Use It

From the developer's perspective, PAT Fortress is a drop-in replacement for api.anthropic.com. The integration is simple:

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  apiKey: "org_api_key_from_kestra_labs",
  baseURL: "https://pat.kestralabs.com/v1",
});

const message = await client.messages.create({
  model: "claude-sonnet-4-5-20250929",
  max_tokens: 1024,
  messages: [
    { role: "user", content: "Hello!" },
  ],
});

console.log(message);

Everything else, request body format, response structure, streaming, tool use, remains identical to the Claude API. Developers don't need to learn a new API.

What Gets Logged

Unlike MCP Fortress (which logs policy decisions only), PAT Fortress logs the full request and response:

• Every prompt sent to Claude
• Every response received from Claude
• Token usage (input/output counts)
• Model, timestamp, user/org, IP address
• Spend per request

All logs are archived to encrypted object storage with server-side encryption. This is critical for SOC 2 Type II audits and compliance evidence.

Usage Visibility

PAT Fortress gives admins visibility into how Claude API keys are being used, but Kestra Labs does not bill for token usage. Your Claude API costs are between your organization and Anthropic. The Settings → PAT Usage dashboard shows per-PAT metrics:

• Request count (total and per-model breakdown)
• Estimated spend based on Anthropic's published rates (for budget planning only)
• Distance to spend cap

Spend caps are a governance feature, they let admins prevent runaway costs by capping how much a given PAT key can consume. Set up email alerts when approaching your cap (e.g., at 80%).

👤 SSO & SCIM

Centralize identity management for Kestra Labs. Use SSO to log in via your corporate directory, and SCIM to automatically provision and deprovision users.

Supported Identity Providers

• Microsoft Entra ID (Azure AD): SAML 2.0 and OIDC
• Okta: SAML 2.0 and OIDC
• Generic SAML 2.0: Any IdP supporting SAML 2.0
• Generic OIDC: Any IdP supporting OpenID Connect

SAML 2.0 Configuration

To configure SAML 2.0 SSO, you'll need:

1. Go to Settings → Identity & Access → SAML 2.0 in the admin dashboard.
2. Copy the following Kestra Labs identifiers:
   • Entity ID: urn:kestralabs:saml
   • ACS URL: https://auth.kestralabs.com/saml/acs
   • Single Logout URL: https://auth.kestralabs.com/saml/sls
3. Provide these to your IdP admin. They'll create an Enterprise Application and give you:
4. • Signing certificate (X.509)
   • Sign-in URL
   • IdP Entity ID
5. Paste the IdP metadata into Kestra Labs. Click Save & Test.
6. Test SSO by logging out and visiting admin.kestralabs.com/login. You'll be redirected to your IdP.

SCIM 2.0 Provisioning

SCIM automatically syncs users and groups from your IdP to Kestra Labs. When a user is added to a group in Entra ID or Okta, they're automatically created in Kestra Labs with the corresponding role.

Enable SCIM in Settings → Identity & Access → SCIM:

1. Copy the SCIM endpoint and API bearer token.
2. Configure in your IdP:
3. • SCIM Endpoint: https://api.kestralabs.com/scim/v2/org_xxx
   • Authorization: Bearer <token>
   • Content-Type: application/scim+json
4. Test the connection. Your IdP will POST a test request to verify the endpoint.
5. Enable user provisioning. New users added to the group will be synced to Kestra Labs in real-time.

Important Notes

🛡️ Policy Configuration

Policies control who can access what. Configure them visually in the admin dashboard, no JSON required. Kestra Labs supports role-based access control (RBAC) with conditional rules for advanced scenarios.

Three-Layer Policy Architecture

Role Setup

To create a new role:

1. Go to Policy Radar → Roles.
2. Click Add Role.
3. Enter a name (e.g., "Support Agent", "Engineer", "Finance Manager").
4. For each connector or API, toggle allowed actions. Use this table format:

After creating the role, assign it to users in Settings → Users & Groups.

Conditional Rules

Enhance role policies with conditional rules. Configure them in Policy Radar → Conditional Rules:

For MCP Fortress: PII Redaction

PII redaction is specific to MCP Fortress (not available for PAT Fortress, which logs full requests). Enable in Policy Radar → PII Redaction:

• Email addresses: Toggle to redact email@domain patterns
• Phone numbers: Toggle to redact +1-555-123-4567 patterns
• Social Security numbers: Toggle to redact XXX-XX-#### patterns
• Credit card numbers: Toggle to redact card patterns
• Custom patterns: (Bank/Zero Trust only) Enter regex patterns for domain-specific PII

When enabled, Kestra Labs strips matching patterns from API responses before returning them to Claude. This is logged in the audit trail.

📡 API Reference

Integrate Kestra Labs programmatically. Use the Gateway APIs to route requests, or the Admin API to manage configuration.

MCP Fortress Gateway API

Endpoint

POST https://gateway.kestralabs.com/v1/mcp

Authentication

Include your org API key in the request header:

x-api-key: org_xxxxxx

Request Format

MCP Fortress accepts MCP JSON-RPC 2.0 requests. Tool names follow the connector__action pattern:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "zendesk__list_tickets",
    "arguments": { "status": "open" }
  }
}

Response Format

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"tickets\": [{\"id\": 123, \"subject\": \"Login Bug\", \"status\": \"open\"}]}"
      }
    ]
  }
}

Error Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Policy denied",
    "data": {
      "reason": "Tool 'zendesk__close_ticket' is denied for your role"
    }
  }
}

PAT Fortress Gateway API

Endpoint

POST https://pat.kestralabs.com/v1/messages

Authentication

All tiers require the org API key. Bank and Zero Trust tiers also require an Entra ID bearer token for identity verification:

# SOHO tier (API key only)
x-api-key: org_xxxxxx

# Bank / Zero Trust tiers (API key + Entra ID required)
x-api-key: org_xxxxxx
Authorization: Bearer <entra_id_token>

Request Format

Identical to the Claude Messages API:

{
  "model": "claude-sonnet-4-5-20250929",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "What is 2+2?"
    }
  ]
}

Response Format

Identical to Claude API (transparent proxy):

{
  "id": "msg_xxx",
  "type": "message",
  "role": "assistant",
  "content": [
    {
      "type": "text",
      "text": "2+2 equals 4."
    }
  ],
  "model": "claude-sonnet-4-5-20250929",
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 10,
    "output_tokens": 5
  }
}

Policy Denial Error (MCP & PAT)

If a policy denies access:

{
  "error": {
    "type": "policy_denied",
    "message": "Access denied: model 'claude-sonnet' is not in your allowlist",
    "code": 403
  }
}

Admin API

Base URL

https://admin.kestralabs.com/api/v1

Authentication

Obtain a identity token (JWT) via /auth/token (username/password or SSO). Include in Authorization header:

Authorization: Bearer <jwt_token>

Existing Endpoints (MCP & Shared)

New PAT Endpoints

New Device Endpoints (Zero Trust)

Webhook Events

Kestra Labs can send webhook events to your infrastructure. Configure in Settings → Webhooks. Supported events:

🖥️ Admin Dashboard

The admin dashboard is your central hub for monitoring, configuring, and managing both MCP Fortress and PAT Fortress. All features are accessible via the web UI, no CLI or API calls required.

Status Board

The main landing page gives you a single-glance overview of your entire Kestra Labs deployment:

Policy Radar

Visual policy configuration for both MCP Fortress and PAT Fortress. See the Policies & RBAC section for the full interactive GUI showing roles, conditional rules, and PII redaction.

Traffic Feed

Real-time request stream showing every MCP and PAT request as it happens, think of it like a security camera feed for your AI traffic:

Vault

Secure credential management with two tabs: one for MCP Connector credentials, one for Claude PAT keys:

Change Log

Immutable audit trail of every admin action, who changed what and when. Searchable and exportable for compliance audits:

Billing

Subscription and usage management: view your tier, user pack, invoices, and payment method. See the Billing & Usage section for full details.

Device Registry (Zero Trust Only)

Cached device posture results, see the Device Posture section for the full device registry interface.

Support Tickets

Need help? Submit a support ticket directly from your dashboard, no email required. Every ticket is tracked, prioritized, and routed to the right team automatically.

💳 Billing & Usage

Simple, transparent pricing for MCP Fortress and PAT Fortress. Purchase individually or bundle both for a discount.

Pricing Tiers

How Users Are Counted

Overage Pricing

If you exceed your pack size, overage users are billed at 1.25× the standard rate. Think of it like a cell plan, stay in your data cap and you're fine, go over and you pay a premium per extra unit.

Zero Trust: Overage pricing is negotiated with your account manager.

Billing Cycle & Pro-Rata

Your billing cycle starts on the date you signed up. All user additions mid-cycle are pro-rated, you only pay for the days remaining. Think of it like a gym membership: add a family member halfway through the month, pay half-price for that first month, full price going forward.

Example: Mixed-Product Scenario (Bank Tier)

Billing cycle starts on the 15th. Here's how the invoice builds:

Next full cycle (Feb 15 → Mar 14), assuming no changes: 60 × $8 + 5 × $5 + 3 × $5 = $520.00/mo.

Bundle Pricing Auto-Applies

The bundle discount is per-user, not per-account. If a single-product user later adds the other product, their rate automatically drops to the bundle rate. No admin action needed.

Payment & Invoicing

📱 Device Posture

Device posture checks are a Zero Trust tier feature. Before any credential is accessed, Kestra Labs verifies the requesting device is compliant, managed, and encrypted.

Overview

Identity alone is not sufficient in a zero-trust model. Even if a user is authenticated, their device might be compromised, outdated, or unmanaged. Device posture adds a second layer of verification:

1. Device Identity: Extract device ID from Entra ID token claims
2. Compliance Check: Query your MDM provider for device state
3. Access Decision: Grant or deny credential access based on device compliance
4. Caching: Cache results for 15 minutes to reduce API calls

Supported Providers

What Gets Checked

Device posture validation checks the following:

• MDM-Managed: Is the device enrolled in your MDM provider (Intune, Jamf, Workspace ONE, or Google Endpoint)?
• Disk Encryption: Is the device's disk encrypted (BitLocker on Windows, FileVault on macOS, dm-crypt on Linux, Chrome OS verified boot)?
• OS Version: Is the OS up-to-date (within N minor versions of latest release)?
• Jailbroken/Rooted: Is the device jailbroken (iOS) or rooted (Android)?
• Compliance Policy: Does the device pass the organization's compliance policy as reported by your MDM provider?

Setup: Intune Integration

1. In Kestra Labs, go to Settings → Device Posture → Intune.
2. Click Connect to Intune. You'll be redirected to Azure consent screen.
3. Grant Kestra Labs permission to read device compliance state. This requires a Global Administrator in your Entra ID tenant.
4. Return to Kestra Labs. The connection is established.
5. Optionally configure Compliance Rules: Set which compliance policies trigger access denial. E.g., "If device compliance policy = 'Failed', deny access."
6. Click Save & Test. Kestra Labs will query Intune for a sample device.

Setup: Jamf Integration

1. In Jamf Pro, create an API user (e.g., "Kestra Labs") with read-only device access.
2. Copy the API username and password.
3. In Kestra Labs, go to Settings → Device Posture → Jamf.
4. Enter your Jamf instance URL (e.g., myjamf.jamfcloud.com), username, and password.
5. Click Test Connection. Kestra Labs queries Jamf to verify credentials.
6. Optionally configure Compliance Rules: E.g., "If encrypted != true, deny access."
7. Click Save.

Setup: Workspace ONE Integration

1. In Workspace ONE UEM console, navigate to Groups & Settings → System → Advanced → API → REST API and enable API access.
2. Create an API key and note your tenant URL (e.g., as123.awmdm.com).
3. In Kestra Labs, go to Settings → Device Posture → Workspace ONE.
4. Enter your tenant URL, API key, and admin credentials.
5. Click Test Connection. Kestra Labs queries Workspace ONE for a sample device.
6. Optionally configure Compliance Rules: Map Workspace ONE compliance policies to Kestra Labs access decisions.
7. Click Save.

Setup: Google Endpoint Management

1. In Google Admin Console, go to Security → API Controls → Domain-wide Delegation.
2. Add a new client ID for Kestra Labs with the scope https://www.googleapis.com/auth/admin.directory.device.mobile.readonly.
3. In Kestra Labs, go to Settings → Device Posture → Google Endpoint.
4. Click Connect to Google Workspace. You'll be redirected to Google OAuth consent.
5. Grant Kestra Labs permission to read device management data. Requires Super Admin role.
6. Click Save & Test. Kestra Labs queries Google Endpoint for a sample device.

How It Works at Request Time

When a user makes a request (MCP or PAT):

1. Identity Check: Kestra Labs validates the user's org API key and Entra ID token.
2. Device Extraction: Kestra Labs extracts the device ID from the Entra ID token claims (e.g., deviceid claim).
3. Cache Lookup: Check if this device was validated in the last 15 minutes (database TTL). If yes, allow or deny immediately.
4. Posture Check: If not cached, call your configured MDM provider's API to fetch device state.
5. Compliance Evaluation: Evaluate the device against your compliance rules.
6. Decision: If compliant, allow the request and cache the result for 15 minutes. If not, deny and return a device_noncompliant error.

Device Registry Dashboard

The Device Registry (in Settings → Device Posture) shows all cached devices:

Force Re-check bypasses the 15-minute cache and immediately re-validates the device. Useful after a user reboots, updates, or installs security patches.

Error Handling

If a device fails posture check:

{
  "error": {
    "type": "device_noncompliant",
    "message": "Device failed compliance check: Encryption status is 'None'",
    "device_id": "device-def456"
  }
}

The user should:

1. Update their device (install OS updates, enable encryption, etc.)
2. Wait for the device to re-check with your MDM provider (can take 5–30 minutes)
3. Retry the request. If the device is now compliant, the request succeeds.