How Nolixan works

Nolixan sits between your agent and the third-party APIs it acts on. Whatever surface you call — a direct action, the proxy, or an MCP tool — the request takes the same governed path.

The path of a call

1. Authenticate — an API-Key (resolves an environment directly) or a JWT identifies who's calling and which environment they're acting in.
2. Resolve the connection — Nolixan looks up the connection for the provider and loads its credentials (decrypted from AES-256-GCM at rest), refreshing OAuth tokens if needed.
3. Govern — the policy gate evaluates the action. It returns allow, deny (the call never runs), or require approval (the call is held until a different person approves it).
4. Execute — the action runs against the provider's API.
5. Audit — the action and the full policy decision are appended to the tamper-evident audit log.

Steps 3 and 5 are what make execution governed — and they apply on every surface, with no extra code from you.

The pieces

• Connections — stored, encrypted credentials for a provider account.
• Actions & tools — a catalog of provider operations named provider__action, with JSON-Schema inputs.
• Surfaces — call an action three ways:
  • directly, via execute;
  • as a native LLM tool through an agent framework;
  • over the MCP server.
• Proxy — a governed passthrough for provider endpoints not yet in the catalog.
• Governance — policy, approvals + separation of duties, and the hash-chained audit trail. The part most tools leave to you.

Multi-tenant by environment

Every connection, policy, and audit event is scoped to an environment. An API-Key belongs to one environment; cross-environment access is not possible.