Skip to main content
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 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. 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 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.

Secret encryption

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.

Security middleware

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. Tilde also records every LLM request with its model, token usage, and cost. See Inference providers. 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, Traces, and 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.

​
What you can choose to make public

The runtime and sidecar routes, and the health endpoints, never need public exposure.

​
Ports

​
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

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.
  • 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.