Your application and agent
Reasons, chooses tools and proposes actions. Your application supplies the authenticated user, resource and task. The agent holds no credential for a protected action.
Phalanx
How Phalanx governs agent actions
Phalanx is a gateway you run in your own infrastructure, between your AI agents and the systems they change. Here is what it checks, how each decision is enforced at execution, what it records, and what your architecture needs.
From proposal to recorded outcome
Three parts stay separate, so the component that proposes an action is never the one that can perform it.
Phalanx
Checks authority and the contract, tracks budgets, evaluates evidence, issues one-use permits and records execution state. It runs as its own service; your business logic is not copied into it.
Protected connector
Holds the business credential, rechecks the permit's conditions, performs the operation and reports the result for verification. It can be your existing API or a small isolated service.
Five steps, every time
Propose.
The agent calls a tool. The SDK adapter sends Phalanx the proposal, with the user and task your application authenticated.
Decide.
Phalanx evaluates the action against its contract, current state, required evidence and remaining limits, and returns PERMIT, HOLD or BLOCK.
Permit.
A permitted action receives a one-use permit bound to that exact operation.
Execute.
The protected connector rechecks the conditions and performs the operation with its own credential.
Verify and record.
Phalanx records the verified result, or marks it uncertain, and links it to the decision.
You define the contract. Phalanx enforces it.
A contract describes one action precisely: what it touches, who may trigger it, where it may go, what state it depends on and which limits apply. Contracts are versioned files that you review and then activate explicitly. Staging a contract does not activate it.
A contract can specify
- The tool, its effect class and the resource it acts on
- The authenticated actor it requires
- The exact connector destination: scheme, host, port, method and path
- A reference to the credential, never the secret itself
- The request and response fields allowed, and the result schema
- State dependencies and revision checks
- When the action is PERMIT, HOLD or BLOCK, and what resolves a HOLD
- Count limits, value limits in exact currency units, evidence freshness and task lifetime
- How the result is verified, and whether the action can be reversed
Six kinds of action
| Effect class | What it governs |
|---|---|
| READ | Retrieving account information or a bounded query result |
| WRITE | Changing a declared record or resource |
| EGRESS | Sending a message or information to an approved destination |
| ACCOUNT_MUTATION | Changing customer or account state |
| FINANCIAL | A monetary operation you declare, in exact currency units |
| EXPORT_SHARE | Exporting or sharing declared information |
These are categories of action, not a catalogue of prebuilt integrations. Each protected action needs a connector to the API that performs it.
Three decisions. Each one means something specific.
| Decision | What it means | What happens |
|---|---|---|
| PERMIT | The action meets every condition in its contract. | A one-use permit lets the connector perform that exact action. Execution and verification are recorded separately. |
| HOLD | An approval, fact or piece of evidence still needs authorized resolution. | Nothing executes. An authorized operator inspects and resolves the HOLD, and Phalanx rechecks the conditions. |
| BLOCK | The action is outside the task's authority or your rules. | No permit is issued. The connector never receives the request. |
HOLD is a real workflow state, not a prompt asking the chatbot to approve itself. Neither the agent nor the caller that proposed the action can resolve it.
Your application decides how each decision appears to your users. Phalanx returns machine-readable results, identifiers and receipt references; the wording is yours.
A good plan is not a permit.
A permit is bound to one action: the signed configuration, the resource, the exact operation and the state it depends on. It works once. The connector rechecks those conditions immediately before it uses the credential.
Connector routes are fixed in configuration. The agent can't supply a new URL, header, credential, protocol or retry policy through its arguments.
If a route is unknown, disabled, mismatched, stale or ambiguous, the action stops. If Phalanx or an evidence source is unavailable, nothing falls back to a direct executor.
Control what the agent can see, not only what it can change.
Sensitive reads go through the same gateway. Protected data is released only after the permitted read has executed and its result matches the declared schema. A held, blocked or failed read returns nothing protected. Bounded list and search queries are supported too, with declared filters and a fixed route.
One task, one budget, across every participating tool.
Without a shared budget, each tool enforces its own limit, and an agent that spreads one task across three tools gets three allowances. In a configured shared workflow, participating tools draw from one task budget. Phalanx records usage across the workflow and applies what remains to every later action.
A workflow can limit
- The total number of actions
- The number of actions per integration
- Money, in an exact currency and unit
- How much information is disclosed
- How long the task lives, bound to one user and session
Budgets are durable, so retries and restarts don't reset recorded usage. A workflow groups 2 to 32 integrations and is opt-in. Tools you don't group keep their own independent limits.
Let your own data decide how much the agent may do.
A task maximum is a ceiling, not an entitlement. With Evidence Bridge, a contract can require an authoritative field in your system, such as an entitlement recorded for the customer, to support the value the agent proposes. Dynamic Autonomy then narrows the agent's authority to what that evidence supports, never above the maximum you set.
Missing, stale, invalid or conflicting evidence never widens authority. The checks are deterministic: numeric values from your system, compared by rules you declared. No model is involved.
When a response is lost, Phalanx doesn't guess.
If a connector accepted an operation but its reply never arrived, the action is marked UNCERTAIN. Phalanx won't send it again blindly. The outcome is reconciled first, using the operation's stable identity. A retry of the same operation is recognised as the same operation; a new action with different arguments is evaluated as new.
What "exactly once" can mean depends on the system at the other end. Some support idempotency keys, some are transactional, some only allow at-most-once delivery. The contract states which applies, and Phalanx enforces it. It doesn't promise exactly-once behaviour from a system that can't provide it.
Records you can verify, not just logs you can read.
Each receipt links a decision to its task, the action, the execution attempt and the verified result. Receipts are signed and form an authenticated, ordered chain, so a missing or altered record is detectable.
Verification tells you what is wrong, not just that something is: an absent receipt, an incomplete chain, a corrupt chain, or verification that couldn't run.
| Status | Meaning |
|---|---|
| PERMITTED | Authorized. Completion not yet verified. |
| EXECUTED | The effect was verified under the connector's contract. |
| HELD | Waiting for authorized resolution. Nothing executed. |
| BLOCKED | Outside authority. Nothing executed. |
| UNCERTAIN | The available evidence can't establish what happened. Reconciliation required. |
Receipts are tamper-evident evidence about the governed execution path. They are not a compliance certification and don't prove facts outside that path.
Runs in your infrastructure, next to the credentials it protects.
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. Authorization decisions happen inside your deployment. Invarra's control plane handles your identity, licence and signed releases.
| Qualified in 1.9 | |
|---|---|
| Self-managed | Linux (amd64) with Docker or Docker Compose |
| Managed on Render | A Render private service on your account, with one writer and a persistent disk |
| Administration | The signed Phalanx CLI on Linux (amd64) |
| Your application | HTTP/JSON or the TypeScript SDK |
| Storage | Persistent storage you own |
Two questions decide whether Phalanx can protect an action.
Can the action be routed through the Phalanx gateway, the SDK or its tool-dispatch adapter?
Can its real credential live behind a protected connector, with every equivalent direct route removed?
Two yeses and it can be protected. Any no, and the architecture has to change first. Your model provider and cloud don't decide it; the execution route does.
Built to be operated, upgraded and recovered.
Administered by CLI and API
A signed CLI and an authenticated admin API cover enrolment, contract review and activation, HOLD resolution, credential and caller management, and receipt verification.
Ready means ready
Readiness reflects loaded, usable authority, not just a running container. An invalid or half-loaded configuration blocks protected actions until it is fixed.
Encrypted backup and verified restore
Full-state backups are encrypted to a key only you hold. Restores are checked against identity and history, and unsafe stale snapshots are rejected.
Upgrades that keep history
Upgrades preserve keys, receipts, budgets and unresolved operations. A rollback restores the matching state and the matching signed image together.
Recovery restores Phalanx's own state. It can't reverse actions already completed in external systems.
What you get, and what Phalanx doesn't do.
Included in the 1.9 release
- Signed runtime image for Linux (amd64)
- Signed customer CLI for administration
- TypeScript SDK @invarra/phalanx, with proposal clients and tool-dispatch adapters
- Versioned JSON schemas for integrations, proposals, workflows, evidence and results
- Example configurations: starting points, never default approvals
- Deployment material for Linux/Docker and Render
- Integration, deployment and recovery documentation, a software bill of materials and third-party notices
Not what Phalanx is for
- Judging whether your chatbot's sentences are true. Phalanx governs actions.
- Learning policy. Decisions follow the rules you declare, over facts you declare.
- Protecting an action the agent can still perform another way. Other credentials and direct routes must be closed.
- Plugging into an application whose tool execution you can't change.
- Running as a service operated by Invarra. You run it.
- Certifying compliance. Records are evidence, not certification.
Questions engineers ask first
How is this different from a guardrail or a scoped API key?
Those check what the agent says, or which tools it may call. Phalanx decides whether a specific action executes, and the agent never holds the credential to act without it. The homepage compares them side by side. Compare
Does Phalanx work with my model provider?
Yes. Phalanx governs the tool calls your agent proposes, not the model. You choose, run and pay for your model separately.
Does Phalanx use AI to make its decisions?
No. Decisions are deterministic: your contracts, applied to declared state and evidence. The runtime is CPU-based and needs no Phalanx-trained model or GPU.
Which integrations are supported?
HTTP/JSON connectors to your own APIs, the TypeScript SDK and generic tool-dispatch adapters. Phalanx doesn't ship vendor-specific connectors; you point a connector at the API that performs the action.
Does it work with MCP?
The supported integration path in 1.9 is HTTP/JSON and the TypeScript SDK. Tell us about your MCP setup; we'll only describe an MCP adapter as supported once it has been qualified.
What happens if Phalanx is unavailable?
Protected actions stop. Nothing falls back to a direct route around the gateway.
Is there a user interface for writing contracts?
The Phalanx contracts interface is in the Invarra customer portal. Guided forms will let you create, edit, validate and version action contracts, shared-workflow limits and supported evidence settings. You'll be able to review a readable summary, approve it and download schema-valid configuration.
How is Phalanx licensed?
Your licence sets the release channel, environments and number of deployments. Contact us for pricing.
Bring one action. We'll show you how Phalanx would govern it.
Tell us what the agent should do, the system it touches and the limit that matters. We'll tell you plainly whether your architecture fits and what an evaluation should prove.