Deployment architectures

Can Phalanx protect your agent's actions?

It depends on one thing: whether each consequential action can be made to pass through Phalanx, with its credential out of the agent's reach. Not your model, and not your cloud.

See the three architectures Deployment overview

Two ways to deploy Phalanx. One architecture it can't protect as-is.

Find the path your agent uses to execute actions today and match it below. No form, and no access to your application needed.

Two questions decide it

Can every action you want protected be routed through the Phalanx gateway, SDK or adapter?
Can its real credential live behind a protected connector, with every equivalent direct route removed?

Two yeses: it can be protected. Any no: not as it stands. This guide helps you self-assess; it doesn't certify an application we haven't seen.

What release 1.9 supplies

An HTTP/JSON proposal gateway; the TypeScript SDK with proposal and workflow clients; generic tool-dispatch adapters for TypeScript; fixed-route HTTP/JSON protected connectors, including a profile for private services; and versioned public schemas. Applications in other languages integrate through the HTTP/JSON gateway. Release 1.9 does not include vendor-specific connectors or a no-code adapter for arbitrary in-process handlers.

Plug, configure, play

Your agent already calls tools through an API you control

Agent → your tool API → Phalanx → protected connector → business system

Point that interface at Phalanx through the HTTP/JSON gateway or the TypeScript SDK. Declare the contracts, move the credential to a protected connector, disable the old direct route, then qualify it. When your interfaces are already supported, this is configuration only.

Adapt, plug, configure, play

Your agent calls functions inside your application

Agent → your dispatcher + Phalanx adapter → Phalanx → protected connector → business system

If your tool dispatcher can take an adapter, the generic TypeScript adapter maps each tool call to its Phalanx integration and adds the trusted resource and operation identity. Expect a one-time hook at the dispatcher, and possibly moving credentialed execution into a separate backend. How much work depends on your code; the adapter itself is reusable.

Can't protect as-is

Your agent executes actions directly and must keep the credential

Agent → direct handler + credential → business system (Phalanx bypassed)

If consequential actions run inside code you can't change, with no tool boundary to hook, and the agent must keep a credential or another direct path, Phalanx can't intercept them. Running Phalanx beside the app does nothing for those actions. The architecture has to change first.

Not sure which one you are?

Describe the path your agent uses to act and we'll tell you which architecture it matches. Leave out credentials and private data.

Ask about your stack