Deployment architectures
Supported application architectures
Phalanx needs a controllable action path—not a particular model or cloud. Use these requirements to identify the integration route before you install it.
Deployment architectures
Two ways to deploy Phalanx. One architecture it cannot protect as-is.
Follow the path your agent uses to execute actions. Choose the architecture below that matches your application before you buy or deploy. This guide does not require a form or access to your application.
Agent action → Phalanx decision → protected connector → business system
1. Plug / configure / play
Configurable tool or API boundary
Agent → configurable tool/API → Phalanx → protected connector → business system
Your agent already sends action requests through a tool endpoint or API that you can point at Phalanx. The business system exposes a connector path, its credential can be removed from the agent, and the old direct route can be disabled. Configure the supported interface, action contracts and protected credential; then verify the route.
2. Adapt / plug / configure / play
Replaceable in-process tool dispatcher
Agent → qualified adapter at tool dispatcher → Phalanx → protected connector
Your agent calls local tool handlers, but its framework has a replaceable dispatcher or tool hook. A Phalanx-supplied adapter qualified for that stack can take over that boundary. Install the adapter, then configure contracts, connector and credential isolation. Without a qualified adapter, this is not a no-code path.
3. Cannot protect as-is
Opaque direct execution with unremovable authority
Agent → direct handler + credential → business system (Phalanx bypassed)
The agent executes consequential actions inside an unchangeable application, offers no replaceable tool or API boundary, and must keep credentials or another direct path to the business system. Phalanx cannot intercept or enforce those actions. Installing its runtime beside the app does not protect them; the application architecture must change.
How to place your system
Can every action you want protected be routed through a supported tool/API boundary or a qualified adapter? Can its real credential live behind a protected connector, with equivalent direct routes removed? If not, that action is not protectable as-is. This guide is not a certification of an unseen application.
What the current product supplies
The released integration plane includes a proposal gateway, declared action contracts, a TypeScript SDK, and protected HTTP/JSON connectors. It does not currently provide a universal, no-code adapter for arbitrary in-process tool handlers. The adapter-assisted pattern is available only when an adapter for that specific stack has been qualified.
Questions about your specific stack?
The guide itself requires no form. If you need help understanding whether an adapter is supported, contact Invarra without sending credentials or private data.