Tool lists
How an agent reaches a system, why two gates apply, and what the narrower one is.
An agent can only touch systems on its tool list, and only in the way the list allows. This is separate from what the workspace's connection permits, and both apply.
Two gates, and the narrower wins
| Gate | Set where | Question it answers |
|---|---|---|
| Connection scope | When the provider is authorised | What could anything in this workspace do with this system? |
| Tool list | Per agent | What may this particular agent do with it? |
A workspace can hold a write-capable connection while every agent in it is read-only through it. That is the safe way to introduce a provider: authorise it at the scope you eventually want, and give the first agent read access only, until you have read a week of traces.
Capabilities
Beyond connectors, an agent carries a small set of capability switches. They are coarse by design — an on/off for a whole class of behaviour rather than a matrix.
- Generative interface
- Whether the agent may structure its output as summary cards and charts rather than prose.
- Voice
- Whether it may use the voice pipeline. See the voice page for which parts of that are connected today.
- Financial bridges
- Open-banking ingestion. Reading is what this enables; anything outbound is routed to a person regardless of the agent's other settings.
Zero-trust settings
- Input sanitisation
- Ingested payloads are stripped of scripts and injection attempts. Server-enforced, not a client-side convenience.
- Rate limiting
- Hard quotas on prompts, tokens and concurrency, with automatic throttling rather than failure.
- Metric syncing
- Continuous heartbeat, token and log reporting to the telemetry endpoint. Turning it off makes an agent harder to diagnose.