Skip to main content
Keep Fentaris deployments safe with centralized identity, policy, secrets, and audit controls.
Start with allow-list policy, authenticated users, scoped upstream servers, and structured logging. Add runtime middleware only for checks that depend on request data.

Quick Start

Declare the proxy with high-level helpers and keep security rules close to the upstream MCP server they govern.
Use allow-list policy in production. Deny rules are useful for explicit exceptions, but the baseline should be the smallest set of tools and capabilities each group needs.

Guard Destructive Tools

Policy should block known destructive tools before runtime middleware runs.
Add middleware when the decision depends on request arguments, tenant state, or a live approval system.

Govern All MCP Capabilities

Tools are only one MCP surface. Resources, resource templates, prompts, and completion can expose data or shape model behavior.
Use list permissions for discovery and direct-operation permissions such as resource:read, prompt:get, and completion:complete before Fentaris forwards a request upstream.

Scope Servers Per Group

Use groups to make server access explicit. This keeps tool visibility, credentials, and policy tied to the caller.
Server-scoped policy also reduces accidental exposure when a new upstream MCP server is added to the proxy.

Compose App-Level Policy And Groups

For incremental proxy setup, declare policies and groups from the app handle before start().
Fentaris validates the final app before serving. Missing named policies, empty groups, duplicate declarations, and policies that still reference missing upstream MCP servers fail startup with configuration diagnostics.

Protect Secrets

Bind secrets through credentials or environment injection. Do not pass secrets through user-controlled metadata or tool arguments.
Store production secrets in your infrastructure secret manager and inject them at deploy time. Keep .fentaris/credentials.enc.json private when using local encrypted credentials.
Do not forward whole environment maps into HTTP headers. Use auth, resolveHeaders, or an explicit envHeaderMap so token-like variables such as GITHUB_TOKEN are not sent upstream unless you map them deliberately.

Validate Identity

When users declare API keys, Fentaris uses API-key identity by default with the x-fentaris-api-key header. Store API keys as credential sources, such as environment variables or encrypted local credentials, instead of literal strings in code. For local encrypted credentials, register a downstream client API key with the CLI:
Trusted identity headers should only be used behind an internal gateway that already authenticated the caller. Do not expose direct user-id headers to untrusted clients.

Audit Decisions

Enable autoLog and add stable tags for traceability. Logs should include metadata, not raw payloads or secret values.
Review denied calls regularly. They show missing policy, unexpected client behavior, or attempted abuse.

Govern Edge Orchestration

Keep Edge Control disabled unless an agent needs inventory or explicit orchestration. When enabled, grant edge__list, edge__get, edge__select, edge__call, and edge__call_many independently. For high-impact fan-out, configure aggregate approval against the exact resolved public-device scope, bounded argument summary, failure policy, concurrency, and deadline. Every child still re-enters normal tool policy and local recipe, grant, and executable consent checks after aggregate approval. Treat device descriptions, tags, observed facts, and MCP child output as untrusted data. Do not accept route, device, correlation, or status fields from device output. Keep device credentials, opaque node IDs, private paths, grant references, secrets, and complete environments out of agent-visible results and telemetry. Use durable multi-instance adapters in production. Atomic inventory versions, monotonic connection generations, sticky/round-robin coordination, atomic result consumption, bounded expiry, and idempotent terminal correlation are security boundaries, not only availability optimizations.

Protect the integrated Edge authority

Treat .fentaris/edge-control-plane as credential-bearing authority state. Keep the directory and files owner-only, exclude them from version control and backups that lack equivalent encryption, and set FENTARIS_AUTH_KEY from a secret provider. Approval must use fentaris edge approve; never edit authority JSON directly. Set an explicit HTTPS publicOrigin behind the trusted TLS terminator. Fentaris ignores hostile Host and forwarded headers when generating join and gateway URLs. Keep the reserved Edge route separate from the MCP path, restrict operator socket access to the application owner, and rotate credentials after suspected disclosure. Local mode is rejected for unsafe multi-instance use. Production replicas need managed adapters with tenant isolation, compare-and-swap desired assignments, monotonic connection generations, durable revocation, and consistent authorization services. Adapter errors fail closed: they must never broaden eligibility or dispatch.

Harden Network Exposure

Run public Fentaris deployments behind a reverse proxy or cloud load balancer.
  • Terminate TLS at the edge and forward only HTTPS traffic.
  • Restrict inbound access with private networks or IP allow-lists.
  • Keep upstream MCP servers private when possible.
  • Rotate API keys and upstream credentials regularly.

Low-Level API

The class constructors remain available for compatibility and advanced embedding. Prefer fentaris(...), mcp(...), stdio(...), streamableHttp(...), group(...), user(...), and policy(...) for new applications.