Control

Agents

Register an agent and it gets its own identity in your organisation: its own keys, scopes and deployment bindings, and its own limits. The records of its model calls and tool calls name the agent, with its owner.

Its own keys

Keys minted for the agent carry explicit scopes. A key with no scopes cannot be minted for an agent.

Bound deployments

Bind the agent to the deployments it may call. Its keys are refused on any other deployment.

Its own request rate

Give the agent its own request-rate limit, separate from the people in your organisation.

Its name on the record

The decision records of its model calls and tool calls name the agent, with its owner.

Register an agent

1. Register the agent

Owners and admins register agents (Manage → Agents, or the API). The person who registers it becomes its owner. Agents are registered in Norcaster; SCIM provisions people, not agents.

curl -X POST https://api.norcaster.com/orgs/ORG_ID/service-accounts \
  -H "X-API-Key: YOUR_ADMIN_KEY" -H "Content-Type: application/json" \
  -d '{
    "name": "refund-agent",
    "kind": "agent",
    "description": "Answers refund questions and proposes refunds",
    "allowed_deployment_ids": ["DEPLOYMENT_ID"],
    "default_scopes": ["runs:write"],
    "budget": { "request_rate_per_minute": 60 }
  }'

2. Mint its key

The key is shown once. It inherits the agent's scopes and deployment binding; give it an expiry if the agent is temporary.

curl -X POST https://api.norcaster.com/orgs/ORG_ID/service-accounts/AGENT_ID/keys \
  -H "X-API-Key: YOUR_ADMIN_KEY" -H "Content-Type: application/json" \
  -d '{"name": "refund-agent production"}'

3. Point the agent at Norcaster with its own key

Use the key wherever the agent calls the gateway, /run or the MCP action gateway. An agent that keeps running on a person's key is recorded as that person.

curl https://api.norcaster.com/v1/chat/completions \
  -H "Authorization: Bearer AGENT_KEY" \
  -H "X-Norcaster-Deployment-Id: DEPLOYMENT_ID" -H "Content-Type: application/json" \
  -d '{"model": "refund-agent", "messages": [{"role": "user", "content": "Where is my refund?"}]}'

Scoped, not unlimited

An agent acts with its owner's authority, narrowed by its scopes and bindings. Give it the scopes it needs and no more: an agent key with the admin scope carries its owner's administrative rights. Its keys keep working if its owner leaves the organisation.

Tool rules come from its deployments

Tool calls made through the MCP action gateway follow the action policy of the deployment the agent calls. An agent bound to one deployment therefore has that deployment's tool rules:

Each tool call is allowed, redacted, blocked, or paused for approval by a person other than the one who asked.
Unregistered tools are blocked by default.
Irreversible actions fail closed: with no allow rule they are blocked or paused, never run.
The approval and the outcome land in the same evidence trail as the model call.

The agent screen (Manage → Agents → the agent) shows them per bound deployment, next to its scopes and limits.

Stopping an agent

Retire it (owners and admins): every key minted for it is revoked at once. Its records stay on the evidence trail.
Stop a deployment it uses (anyone who can deploy to it): its calls to that deployment are refused.
Engage the kill switch (owners and admins): all runtime traffic for the organisation is refused, this agent's included.

Each stop is recorded with who, when and why, and every refused request is a blocked decision on the evidence record. See the kill switch for what happens to work already in flight.

What identity covers today

Identity holds inside your organisation. Another company cannot verify your agents yet.
On a record, the agent is named by its id; the user id on the record is its owner.
Approvals wait in the portal queue; there are no named approvers or notifications when a call pauses.