Route the action
Each protected tool call can be sent through the Phalanx SDK adapter or the HTTP/JSON gateway.
Deploy Phalanx
Deploy Phalanx in the path of your agent's actions.
Phalanx can only govern an action that has to pass through it. Before installing anything, confirm that your agent's tool calls can be routed through Phalanx and that the real credentials can sit behind a protected connector.
Four requirements. None of them is your model or your cloud.
The model provider and hosting platform don't decide whether Phalanx fits. The execution route does.
Supply trusted identity
Your application signs the authenticated user, session and resource for each proposal. Phalanx never takes identity from the chat.
Separate the credential
The credential that performs the action lives with a protected connector, outside the agent's process.
Close the bypass
No other credentialed route can perform the same action around Phalanx.
The architecture guide shows the two supported integration paths, and the design Phalanx can't protect as-is.
Where Phalanx runs
Phalanx is a separate service in your infrastructure. The usual footprint is one Phalanx service plus persistent storage. Add a protected backend only if your agent's process holds business credentials today; that is one boundary, not one service per tool.
Sizing depends on your tool catalogue, concurrency, retention and recovery headroom. Release 1.9 was qualified at 0.5 CPU and 512 MB for its test workload, and the Meridian demo runs at 1 CPU and 2 GB. Neither figure is a minimum or a throughput promise; we size with you during evaluation.
Invarra's control plane handles your identity, licence and signed releases. Authorization decisions happen inside your deployment. The Render option is hosting you manage on your own account, not a service Invarra operates.
| Qualified in 1.9 | |
|---|---|
| Self-managed | Linux (amd64) with Docker or Docker Compose, from the signed, verified image |
| Managed on Render | A Render private service on your account, with one writer, a persistent disk and a private administration channel |
| Administration | The Phalanx CLI on a Linux (amd64) machine; it can be separate from the runtime host |
| Your application | Connects over HTTP/JSON or the TypeScript SDK; your application runs separately |
| Same-host connection | Loopback, with separate local credentials per role |
| Separate-host connection | TLS with Ed25519-signed requests, or the qualified private network on Render |
| Storage | Persistent storage you own. Ephemeral storage isn't supported. |
| Scaling | One writer per authoritative state store |
Other clouds, storage types, and macOS or Windows administration aren't qualified in 1.9. Ask before planning on them.
From first check to a protected action
Check compatibility
Pick the actions to protect. Confirm each can be routed through Phalanx with its credential behind a connector.
Deploy and qualify the runtime
Install the signed release with the CLI. Setup plans show what will be created or reused, and nothing changes until you approve. Then run the readiness and qualification checks.
Enrol and activate your actions
Declare each action's contract and connector, connect the adapter at your tool dispatcher, and activate the reviewed configuration.
Verify protection
Test the real agent path: permitted actions, HOLDs, BLOCKs, retries, receipts, and the absence of any bypass. A running gateway with nothing enrolled protects nothing.
Who is involved
One person can hold several of these roles. The agent's credentials stay separate from all of them.
| Role | Responsible for |
|---|---|
| Business or policy owner | Which actions are allowed, what needs approval, the limits, and what the required evidence means |
| Application engineer | Connecting the tool dispatcher, supplying trusted user and task context, handling results in the app |
| Platform engineer | Installing the runtime, networking, durable storage, separating credentials, qualifying the deployment |
| Operator | Resolving HOLDs, managing integrations and callers, verifying receipts, maintenance |
| Security owner | Reviewing credential isolation, authorization, trust boundaries and closed bypass routes |
Evaluate Phalanx on one real workflow.
An evaluation starts with three things: an action that should work, a boundary that must hold, and an outcome you need to verify. Bring those and the tools involved.
We'll tell you whether your architecture fits as it is, needs an adapter hook or a separate backend, or can't be protected without a change. Please don't send credentials or private customer data.