> ## Documentation Index
> Fetch the complete documentation index at: https://docs.walletsuite.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Agents and Authority
> What an AI agent is in WalletSuite, and how the LLM proposes while a deterministic policy engine authorizes.
An **AI agent** is a first-class non-human principal in the money-movement control plane. It is not an LLM, and it is never the authorizer. The model that drives an agent proposes transactions. The mandate is the authority. The signing layer only completes signatures that cleared policy.
The LLM is an untrusted proposer. Authority lives in the mandate, evaluated by a deterministic engine with no LLM in the decision path. A proposal is only signed if it satisfies the agent's policy.
## An agent is five bound things
"Give your agent a wallet" means minting an agent as a scoped, revocable principal. An agent is exactly five bound things.
| Part | What it binds |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Identity** | Each agent has its own scoped, revocable key — the agent's quota, billing, and revocation anchor. Your server uses it to authorize the agent; the raw key never reaches the model, only a short-lived token does. See [Connect your agent](/ai-agents/token-exchange). |
| **Wallet grant** | A binding to a specific non-custodial [MPC wallet](/security/overview#trust-model) — the agent can propose, but can never move funds alone. The grant also fixes the chains the agent can act on. |
| **Mandate** | One or more deny-by-default allowlist rules the agent must satisfy. See [Policy Gates](/core-concepts/policy-gates) for the rule anatomy. |
| **Budget** | A cumulative spend envelope, the machine-scale analog of a card limit, drawn down atomically across the agent's intents. |
| **Expiry** | A mandatory time bound. Authority is never open-ended. |
Identity, wallet grant, and mandate scope what an agent is and what it may sign. Budget bounds how much it may move. Expiry closes the loop so no agent holds authority forever.
An agent is addressed by a stable `agentId`; a managed or embedded assistant adds an `assistantId`. How it is selected, and why one organization runs many agents and assistants, are cross-surface invariants — see [Choose your surface → Invariants](/ai-agents/choose-your-setup#invariants-across-every-surface).
## Proposer versus authorizer
WalletSuite separates the actor that decides *what to try* from the function that decides *what is allowed*. These are different trust levels and they run in different places.
| Role | Who | Trust level |
| -------------- | ------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Proposer** | The LLM or agent framework | Untrusted. It suggests a transaction. It holds no authority. |
| **Authorizer** | The deterministic policy engine (PDP) | Trusted. No LLM in the path. It evaluates the proposal against the mandate and returns allow or deny. |
| **Completer** | The MPC signing layer | The cosigner releases its share only for an intent that cleared policy. A denied intent is never signed. |
The authorizer checks every proposal against your deny-by-default allowlist rules before any share is released, and records the decision. See [Policy Gates](/core-concepts/policy-gates) for the rule model and [Policy Decisions](/core-concepts/policy-decisions) for the decision record.
Because the model never authorizes, a poisoned prompt or a misaligned proposal cannot exceed the mandate. The worst an LLM can do is propose a transaction the engine denies.
## How each surface carries authority
The mandate is the same object across every surface. Only the way an agent reaches it differs.
Agents connect to the hosted MCP server with a short-lived token. The tool profile bounds which tools exist in the schema, and the mandate bounds what a tool can do. The MCP layer proposes; it never authorizes.
Application code calls the SDK to construct and submit intents. The same mandate is evaluated on every signing request.
Any language calls the REST API directly. The policy engine sits in front of the signing path, so the same authorization applies regardless of surface.
The mandate is a signing-layer control that applies to every surface. A narrow tool profile plus an armed mandate gives an agent the smallest possible tool surface and the smallest possible signing authority at once. See [Architecture](/core-concepts/architecture) for how the three surfaces compose.
## Related
* [Policy Gates](/core-concepts/policy-gates) - the rule anatomy, deny-by-default matching, and the off/shadow/enforce modes
* [Policy Decisions](/core-concepts/policy-decisions) - decision records and enforcement evidence
* [Connect your agent](/ai-agents/token-exchange) - the agent credential and token exchange
* [Execution Levels](/ai-agents/execution-levels) - what an agent can do, from read to governed execution
* [Security Overview](/security/overview) - the cross-surface trust model