> ## Documentation Index > Fetch the complete documentation index at: https://trytilde.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Security overview > How Tilde protects agents, credentials, and conversations: no agent endpoints, short-lived tokens, encryption, middleware, audit data, and network exposure. Tilde puts one governed gateway between each agent and everything it touches. Agents hold no credentials and expose no endpoints. Every message, tool call, and LLM request passes through a point where you can authenticate it, screen it, and record it. This page covers each layer. It links to the detailed pages where they exist. ## Agents expose no API endpoints An agent never listens for requests. On startup, the Tilde SDK opens one outbound HTTP/2 stream to the gateway, or to its sidecar, and authenticates with a deployment token. Tilde delivers every invocation as a frame on that stream. This removes a whole class of attack: * There is no agent URL to scan, fuzz, or flood. * The agent needs no Kubernetes Service, Ingress, or load balancer, and no inbound firewall rule. * A compromised network peer cannot call the agent directly, because nothing on the agent accepts a connection. * Tilde stores only a hash of each deployment token. You can rotate a token at any time, and a retired deployment's token stops working at once. See [Agent Registry](/docs/agent-registry#agent-lifecycle) for the full connection lifecycle. ## Short-lived tokens for every invocation An agent's deployment token only lets it connect and wait. It grants no access to tools, models, or conversations. For each invocation, the gateway issues a separate signed token scoped to that one piece of work. | Property | Value | | - | - | | Format | A signed token, verified on every call. | | Lifetime | Minutes. | | Bound to | One invocation, agent, conversation, and participant. | | Carries | The agent's capabilities and its assigned inference connections. | | Renewal | Automatic while the invocation is active. Renewal can narrow authority, and can never widen it. | | Revocation | Cancelling, pausing, or losing access blocks renewal. | The agent uses this token for every tool call, LLM request, and telemetry upload. The token never appears in thread history. The signing key is itself encrypted at rest. A stolen invocation token is therefore worth very little. It expires in minutes, it works for one conversation, and it cannot do anything the agent was not already granted. See [IAM](/docs/iam) for the capability model. ## Secrets are encrypted with a key you control Tilde uses envelope encryption with AES-256-GCM. An envelope encryption key, held in AWS KMS or supplied by you, protects a data encryption key. That key encrypts every connection credential, OAuth token, and signing key before it reaches PostgreSQL. * Each ciphertext is bound to its record and field, so it cannot be moved elsewhere. * Decrypted credentials stay in memory only briefly, in buffers that are wiped when released. * Secrets are carried in types that cannot be logged or serialized. * Agents never receive provider credentials. They invoke tools, LLM providers, and reverse proxies through the gateway, and the gateway injects the credentials before it sends each request upstream. Key providers, algorithms, in-memory handling, and standards alignment. ## Security middleware screens input and output ENTERPRISE Security middleware inspects text on its way into and out of each agent. It runs in the gateway and in sidecars, before the agent sees a message and before a reply reaches a user. Six guards are available: PII, secrets, jailbreak and prompt injection, NSFW, toxicity, and a custom guard that runs your own JavaScript in a restricted sandbox. Each guard can flag, redact, or block. Every guard fails closed. Guards, actions, custom scripts, and what each decision records. ## Audit data for every session Tilde records what each agent did, so you can review any conversation after the fact. You find this data in three tabs on each agent in the Agent Registry. | Tab | What it records | Where it is stored | | - | - | - | | **Sessions** | Each conversation thread: messages, agent reasoning, tool calls, and security middleware decisions. | PostgreSQL holds the canonical messages, immutable audit snapshots, and thread activity. | | **Tracing** | Each invocation as a trace: model calls, tool calls, latency, token usage, cost, and errors. | ClickHouse, with large payloads and media in object storage. | | **Logs** | Structured agent logs, tagged with agent, deployment, invocation, run, and thread. | ClickHouse. | Tilde also records every LLM request with its model, token usage, and cost. See [Inference providers](/docs/inference-providers#usage-and-cost). Audit records are designed to be safe to keep: * The server sets identifying attributes such as agent, invocation, and thread. An agent cannot forge them. * Security middleware decisions name the guard, label, and score, and never the matched text. * A message blocked on the way in is never stored. * Prompts and tool inputs appear in traces only if your framework's instrumentation opts in. * Attachment bytes are encrypted, and never appear in audit snapshots. Treat all three stores as sensitive conversation data. Restrict access to them, and encrypt their disks and backups. See [Sessions](/docs/sessions), [Traces](/docs/traces), and [OpenTelemetry](/docs/integrations/opentelemetry). ## Network exposure This section applies when you run the gateway yourself, with Tilde OSS or Tilde Enterprise. In Tilde Cloud, Tilde runs the gateway and its network. The gateway listens on one port, `8080`, behind your HTTPS ingress. Most deployments need no public exposure at all. You decide what is public by choosing which routes your public ingress forwards. ### Gateway route groups The gateway serves four route groups on the same listener. Each has its own authentication. | Route group | Serves | Authentication | Exposure | | - | - | - | - | | Management | The UI, the management API, and operator login | Your identity provider, or a management API key, in Cloud and Enterprise | Private. | | Runtime | Agent runtime calls, inference, and telemetry | Signed invocation tokens | Private. Only your agents call it. | | Ingress | Provider webhooks and native chat | Provider signatures, or scoped tokens | Public only if you use public chat providers or clients. | | Sidecar | The sidecar protocol | Agent deployment tokens | Private. Only your sidecars call it. | ### What you can choose to make public | Make it public when | What is exposed | | - | - | | A public chat provider, such as Slack, WhatsApp, Telnyx, MS Teams, or AgentMail, must deliver webhooks. | The webhook route only. Tilde verifies each provider's signature. Telnyx Voice also uses a secure WebSocket for each call. | | External clients use native Tilde chat, for example a customer-facing chat widget. | The native chat route only, authenticated with scoped tokens. | | Operators or users sign in or set up connections from outside your network. | The login and connection setup callbacks. | The runtime and sidecar routes, and the health endpoints, never need public exposure. ### Ports | Service and port | Who reaches it | Public exposure | | - | - | - | | HTTPS ingress `443` | Private clients by default | Optional, for the routes above only. | | Gateway `8080` | Your ingress and authorized private workloads | Never directly. | | Sidecar runtime `8081` | Loopback inside the pod or task | Never. The sidecar enforces loopback binding. | | Sidecar ingress `8082` | Private ingress and peer replicas | Optional, through HTTPS `443`, when clients bypass the gateway. | | Databases and object storage | Tilde services only | Never. | | Your OpenTelemetry collector | The gateway | Never. | ### Isolate route groups You can run the public ingress routes and the private management routes as separate gateway processes. A compromise of the public processes then reaches no management route. ### Outbound access | From | To | Why | | - | - | - | | Gateway | Your identity provider | OIDC login, in Cloud and Enterprise. | | Gateway | LLM providers | Inference for direct and Lambda agents. | | Sidecars | LLM providers | Inference for sidecar agents. | | Gateway | Chat and tool providers | Sending messages and calling provider APIs. | | Gateway | AWS APIs | KMS and Lambda, when configured. | | Gateway | Object storage | The telemetry queue, trace media, skill files, and attachments. | | Gateway | GitHub | Syncing Git and catalog skill sources. | Agent containers need no internet egress for inference. They reach only the gateway or their sidecar. ## Deployment checklist * Terminate TLS at every network boundary. * Restrict traffic with security groups or network policies. * Use AWS KMS for the envelope key in every cloud environment. * Keep management API keys out of agent containers. See [IAM](/docs/iam). * In Tilde Enterprise, enable security middleware on every agent that handles customer input. * After you deploy, verify private reachability, public route restrictions, agent reconnection, and telemetry delivery.