InvarraCustomer portal

Execution control for AI agents

Once an agent can act, its mistakes leave the conversation.

A wrong answer can be corrected in the next message. A changed record, a disclosed file or a repeated operation has already happened. Phalanx sits between your AI agents and your business systems, and lets a protected action execute only when it is inside the authority you defined.

Try the live demoSee how Phalanx works
Phalanx decides which of a support agent's proposed actions execute Illustration. A support agent proposes three actions in turn. Looking up the signed-in customer's account passes every check and is permitted; a protected connector performs the read and the result is recorded as executed. Changing the plan on the account needs an operator's approval, so it is held; nothing executes. Emailing the case history to an outside address breaks the destination rule and is blocked; the connector is never called. The agent proposes Phalanx checks Authenticated task and customer Rules for this action Current state Remaining limits PERMIT HOLD BLOCK One-use permit issued Waits for an operator No permit issued Look up the signed-in customer's account Within the task's read limit PERMIT One-use permit issued Connector reads it Recorded: EXECUTED Change the plan on account A-102 Plan changes need approval HOLD Waits for an operator Nothing executes Recorded: HELD Email the case history to an outside address Destination not approved BLOCK No permit issued Connector never called Recorded: BLOCKED
Phalanx decides which of a support agent's proposed actions execute Illustration. A support agent proposes three actions in turn. Looking up the signed-in customer's account passes every check and is permitted; a protected connector performs the read. Changing the plan on the account needs an operator's approval, so it is held. Emailing the case history to an outside address breaks the destination rule and is blocked. The agent proposes Phalanx checks Authenticated task and customer Rules for this action Current state Remaining limits PERMIT HOLD BLOCK One-use permit issued Waits for an operator No permit issued Look up the signed-incustomer's account All conditions met. Within the read limit. PERMIT One-use permit issued Connector reads it Recorded: EXECUTED Change the plan on account A-102 Plan changes need an operator's approval. HOLD Waits for an operator Nothing executes Recorded: HELD Email the case historyto an outside address Destination not approved for this task. BLOCK No permit issued Connector never called Recorded: BLOCKED
Illustrative. A support agent proposes three actions; the rules you set decide each one.
  • Production release 1.9
  • Runs in your infrastructure
  • No model in the decision path

Capable agents fail in ordinary ways.

None of these needs an attacker. Each happens when a reasonable-looking plan meets a live system.

The wrong customer Illustration. Customer 4471 is signed in. A message in the conversation mentions account 8812, and the agent acts on account 8812 instead of the signed-in account. Signed in: 4471 "…and update account 8812" Account 4471 signed in Account 8812 changed

The wrong customer

Another customer's ID comes up in the conversation, and the agent acts on that account instead of the one that is signed in.

The same action twice Illustration. The agent sends a case update. The reply is lost, the agent retries, and the customer receives the same update twice, five seconds apart. Agent Email service reply lost, agent retries Case update sent 10:02:14 Case update sent 10:02:19

The same action twice

A response is lost, the agent tries again, and the operation runs a second time.

The stale overwrite Illustration. The agent reads version 7 of a record. A colleague then saves version 8. The agent writes back its version 7 data, overwriting the colleague's change. Record: case 5521 Agent reads v7: open Colleague saves v8: escalated Agent writes v7 data The escalation is silently lost

The stale overwrite

The agent reads a record, someone else updates it, and the agent writes back what it saw earlier.

The wrong destination Illustration. The agent sends a case history. Instead of the approved company address, it goes to an address at an outside domain. Case history 12 messages approved @yourco.com outside @other.com

The wrong destination

A case history goes to an address outside the company, because someone asked for it or because it seemed helpful.

Every limit kept, the total exceeded Illustration. Three tools each use about 60 percent of their own limit, so each looks fine. Together they use nearly twice what the whole task was meant to allow. Tool A Tool B Tool C each within limit Task task limit exceeded

Every limit kept, the total exceeded

Three tools each stay within their own limit. Together they do far more than the task ever allowed.

Each one is a well-formed tool call. That is why it gets through.

Your current controls check what the agent says. These are things it does.

Each control below is useful. None was built to decide whether this action, for this customer, in the current state, should execute now.

If you rely onIt's built toWhere it falls short
Prompt guardrails and classifiersJudge whether text looks harmfulAll five scenarios look like ordinary, polite tool calls
Scoped API keys and tool allowlistsDecide which tools an agent may useThe key doesn't know which customer is signed in, whether the record changed, or what other tools already did
Checks inside each tool handlerEnforce whatever you wrote for that toolEach tool sees only itself, and the check runs in the same process that holds the credential
A person approving every actionCatch mistakes by reviewIt works until the volume turns review into a formality, and it removes the reason to have an agent

The one check that can't be skipped is the one at the point of execution.

Control the action where it executes. Take the key away from the agent.

If the agent holds a credential, every other check is advisory: a wrong plan can still run. Phalanx moves the credential out of the agent's reach. The agent can only propose.

Phalanx checks each proposal against the authenticated task, your rules, the current state and the remaining limits. Only a one-use permit lets a protected connector, the component that holds the credential, carry it out. Then Phalanx records what happened, including when the outcome is uncertain.

Without Phalanx the agent holds the credential; with Phalanx it can only propose Top: an AI agent holds the key to the account API and can call it directly, so whatever it decides, it can do. Bottom: the agent holds no key and sends a proposal to Phalanx. Only a one-use permit reaches the protected connector, which holds the key and calls the account API. Without an execution boundary AI agent holds the API key Account API any call it decides Whatever the agent decides, it can do. With Phalanx AI agent no credential proposes Phalanx decides each action one-use permit Protected connector Account API The agent can only propose. The key sits with the connector, and only a permitted action reaches it. Illustrative. Holds for every action enrolled behind Phalanx.

How the five scenarios end

ScenarioWith Phalanx in the path
The wrong customerThe customer comes from your login, not the chat, so a different account is outside the task and the action is blocked.
The same action twiceA retry is recognised as the same operation. A lost response is reconciled before anything is sent again.
The stale overwriteThe contract's state check sees the record changed, and the write stops.
The wrong destinationThe destination isn't approved for this action, so no permit is issued.
Every limit kept, the total exceededIn a configured shared workflow, every tool draws from one task budget. Another tool doesn't mean another allowance.
See how Phalanx works

What changes when Phalanx is in the path

Engineering

Engineering ships an agent that acts

Your rules live outside the prompt and your credentials outside the agent. The agent can do real work without holding the keys to do anything.

Security

Security reviews one boundary

Which credentials exist, where they live, and what each protected action may do: one place to inspect, instead of every prompt.

Operators

Operators can answer "what happened?"

A signed record shows what was proposed, decided, executed and verified, and what still needs a person. Actions on HOLD wait for them.

See it on a working agent.

Explore Phalanx in Meridian, a synthetic customer platform. Phalanx controls selected enrolled action paths and records their decisions, execution and outcomes. Ask the support chatbot about your account, and the answer comes from a protected read with its own receipt.

Phalanx 1.9 is a production release, qualified on its signed artifacts before delivery.

Try the live demoSee the release evidence

Runs in your infrastructure, on Linux with Docker or on Render. Deployment

A protected read in the Meridian demo Illustration of a support chat in Meridian, a synthetic business. A customer asks about the status of their own account. Phalanx permits the protected READ for that customer's account, the connector executes it, and the answer carries a receipt. The customer then asks for another company's account; Phalanx blocks the read, so no data is released. Meridian Cloud support synthetic data What's my account status? READ PERMIT EXECUTED receipt r_2c81 Your account is active, with two open support cases. Show me Acme Ltd's account too. READ BLOCK not this customer's resource I can only access the account you're signed in to. Illustrative. The demo's introduction lists the live controls.

Which action would you trust your agent to take next?

Bring one workflow, the tools it uses and the limits that matter. We'll show where Phalanx fits, what your architecture needs, and what an evaluation should prove.

Discuss your workflowTry the live demo