Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Security & Guardrails

Amodal provides runtime authentication, scoped agent data, connection permissions, and configurable guardrail hooks. Their coverage depends on the execution path and the agent's configuration.

Authentication and scope

Hosted chat, session, and store requests require runtime authentication. Public app access does not grant chat access. See Authentication.

Use verified identity for authorization. A verified JWT scope_id takes precedence over a client-supplied scope. Request context can contain untrusted values even when a JWT supplies other context keys.

Session history and resume do not enforce token scope. For a multi-tenant application, keep runtime credentials on your backend and authorize every scope, session, and operation before proxying it. A browser-held runtime token can bypass those checks. See Embedding.

Guardrail hooks

Hooks can inspect, block, or modify input, model tool calls, string tool results, and assistant text on the chat loop that loads them. Define hooks under hooks/ or include them from an agent package.

Hook pointUse
preInputReject or redact incoming text before it enters the conversation.
preToolUseCheck permissions or rewrite arguments before a model tool call.
postToolUseRedact or withhold a string tool result before it returns to the model.
preOutputRedact or withhold assistant text before it reaches the user.

When hooks are loaded, the runtime buffers assistant text until the output hook chain completes. Structured tool results and reasoning content do not pass through these text filters. The delegated-agent runner does not inherit the parent chat hook chain. Custom handlers must enforce permissions on their own direct side effects.

A hook that throws or times out follows its failPolicy. The default is closed for these four points. A malformed hook can be skipped during loading, so check the hook inventory and warnings as well as testing individual decisions.

Field scrubbing and output filtering

The core library provides a field scrubber and an output guard. The hosted chat runtime does not automatically apply the core library's three-stage output guard to every response. Configure and test hooks for the redaction your agent requires.

Where a runtime host supplies a field scrubber, restrictions apply only when the response shape and endpoint mapping match its policy configuration. The generic REST scrubber uses exact endpoint lookup; templated paths and flat response objects may not match. Test representative responses.

Connection policy.json restrictions have these meanings when matched:

PolicyScrubber behavior
never_retrieveRemove the field before returning the response to the model.
retrieve_but_redactKeep the value in model-visible data and track it for a separately configured output filter.
role_gatedRemove the field. The field scrubber does not evaluate allowedRoles.

The core output guard can redact tracked values, scan SSN/credit-card/bank-account patterns, and detect tracked-value leaks. Having that library available does not establish that a deployed chat path uses it. Verify the configured path with an eval containing the values that must be withheld.

Write permissions and confirmations

For model calls to connection tools, policy.json controls whether a write may run and whether it needs approval. Native OpenAPI writes without a matching endpoint policy are denied.

confirm on a matching policyBehavior
OmittedAllow the operation without an approval prompt.
trueAsk for approval before execution.
"review"Refuse execution because human review is required. A chat approval does not queue or execute the call.
"never"Block execution.

Thresholds can escalate the required tier based on request parameters:

{ "field": "body.amount", "above": 10000, "escalate": "review" }

For calls marked delegated, delegations.escalateConfirm: true escalates confirm to review. Your application owns any separate review workflow.

A custom tool's direct ctx.request call does not apply the model tool-call permission checker. Enforce the required permission in the handler or the receiving API. See Confirmation Model for each tool path.

Tool and skill access

An agent's declared tools, skills, connections, and stores determine the resources available to its session. Conditional entries can check verified claims through ctx.claims. Runtime HTTP roles (user, admin, ops) are separate from these resource declarations.

Use "*" to allow all resources of a kind. A named agent's subagents list controls which agents it can delegate to through call_subagent. See Agents for declarations and defaults.

Execution limits

LimitDefaultEffect
Model turns50Stops a chat run that reaches its turn limit.
Turn deadline10 minutes when no caller signal is suppliedAborts the turn through its cancellation signal.
Repeated tool callsDisabledmaxToolRepeats enables detection of repeated calls with similar arguments in the last 16 messages; detection requires at least 3 repeats.

Activity and logs

Use Sessions to inspect messages, tool calls, usage, and run status. Use runtime logs for tool execution and guardrail decisions. Activity records platform actions such as deployments and configuration changes. These views serve different purposes; a platform activity list is not a complete record of every agent side effect.