The demo is the easy part.

Bound parameters

An agent cannot fetch a customer it was never shown.

You declare which parameters belong to the signed-in end user. AXONIC then does something stronger than filtering the result: it removes the parameter from the JSON Schema the model sees, so the model is never told the field exists, and fills it in from the verified session after the model has spoken.

A parameter that is absent from the schema cannot be guessed, cannot be named, and cannot be argued into by anything a user types. Prompt injection has nothing to reach for.

1. 1 · Activation

   Is this tool exposed to end-user sessions at all? end_user_exposed is off by default, per tool, per environment.

2. 2 · Projection

   Bound parameters are stripped from properties, stripped from required, and additionalProperties is forced to false.

3. 3 · Rejection

   If the model sends a bound parameter anyway — including a case-variant probe — the call is refused and recorded, not silently corrected. Silently winning would hide the attack.

4. 4 · Injection

   Only now is the real value merged in, from the verified session. It can never come from the request, a header, or a literal.

{
  "bind": [
    {
      "param": "customer_id",
      "from":  "end_user.external_id"
    }
  ],
  // Default is CLOSED. An unbound read on an
  // end-user-exposed tool is refused, not allowed.
  "requireBoundFilter": true
}

// A source the caller could influence is rejected
// at parse time. These four are the whole list:
"end_user.id"
"end_user.external_id"
"end_user.email"
"end_user.metadata.<key>"

model asks for  { "limit": 20, "status": "open" }

dana's session  { …, "customer_id": "cus_dana"  }
priya's session { …, "customer_id": "cus_priya" }

if dana's session sends customer_id itself:
refused  scope_violation
logged   model_supplied_bound_param
class    needs_human

dev / prod

The thing you test against is not the thing your customers hit.

Each project has a dev and a prod environment with their own connections, their own tools and their own API keys — pk_test and sk_test against pk_live and sk_live. Allowed browser origins are per-environment too.

A tool active in dev is not callable in prod until it is promoted, and promotion lands it back in draft — approval never rides along. Trying to activate a prod tool pointed at a dev connection is refused outright.

One honest caveat: connections, tools, keys and origins are environment-scoped; the secret vault itself is scoped to the project, and a connection binds a specific secret to a specific environment.

What this costs

import { createSession } from '@axonic/client/server';

const session = await createSession({
  secretKey: process.env.AXONIC_SECRET_KEY!, // server only
  endUserId: user.id,
  email: user.email,
  metadata: { org_id: user.orgId },
  ttlSeconds: 900,
});

// Everything bound to end_user.* now resolves
// from THIS session, for every tool call it makes.

import { AxonicProvider, useAgent } from '@axonic/client/react';

const { messages, send, isStreaming,
        toolCalls, pendingApproval,
        decideApproval } = useAgent();

curl -X POST "$BASE/connectors/generate?environment=dev" \
  -H 'content-type: application/json' \
  -d '{"source":"openapi","url":"…/openapi.json"}'

// → every generated tool is a draft. None is callable
//   until it passes its evals and a human approves it.