Classic zero-trust principles applied to every resource, every request, every agent, every tool. No implicit trust because someone's on the VPN. No "admin by default". Every decision logged.

The principles

1. Never trust, always verify — every request authenticated and authorized at the resource level, not at the perimeter
2. Least privilege — access granted is the narrowest that makes the task possible
3. Explicit allowlists — agents and tools require specific grants, not implicit access by being “inside the firewall”
4. Log everything — every decision is an audit event

How it applies to users

A user’s request to read a document:

1. Session authenticated (SSO token verified, MFA if required)
2. Base membership checked
3. Collection access checked
4. Document-level ACL checked (including inherited restrictions)
5. Redaction rules applied if user’s role is limited (e.g. external reviewer)
6. Access event written to audit log
7. Response returned — or denied, with a specific error pointing to the policy that blocked it

How it applies to agents

Agents are first-class zero-trust citizens. An agent has an explicit scope:

• Tool allowlist — an agent can only call tools listed in its configuration. An agent without send_email in its allowlist cannot send email, even if prompted to.
• Knowledge scope — an agent can only see collections it’s been granted. A research agent in Base A cannot query Base B’s corpus.
• Output schema — if an agent is constrained to a specific output schema, it cannot produce arbitrary free-form responses.
• Rate limits — per-agent call budgets prevent runaway loops.

Prompt injection defence

Zero-trust for agents means an attacker-controlled prompt cannot trick an agent into doing things outside its allowlist:

• An agent can’t grant itself new tools via prompt injection — new tools require an admin config change
• An agent can’t exfiltrate data to an unauthorized endpoint — outbound calls are restricted to the allowlist
• An agent can’t escalate privileges to read other Bases — each agent instance is Base-scoped

How it applies to tools

Tools — built-in and custom — are not trusted unconditionally. Each tool call:

• Verifies the calling agent has that tool in its allowlist
• Applies per-tool rate limits
• Runs input validation (payload size, schema conformance)
• Captures the call in the audit log
• Applies output redaction if the tool returns data the caller shouldn’t see

How it applies to workflows

Workflows inherit the permissions of the user or agent that triggers them. A workflow that does three tool calls, each of which touches sensitive data, will fail at step two if the caller lacks access — not proceed to step three with stale authorization.

Permission model

Principal	Can hold permissions on…
User	Bases, collections, documents, agents, workflows, tools
Group	Same — groups inherit to members
Agent	Knowledge scope (read), tool allowlist (execute), output schema
Service account	Same as user — but API-only, no interactive session
External user	Time-limited scoped access, no default

Policy evaluation

Permissions are evaluated top-down with explicit deny winning over allow. The order:

1. Explicit deny for this specific principal + resource
2. Explicit allow for this specific principal + resource
3. Group-inherited permissions
4. Base-default permissions
5. Deny (implicit)

Session management

• Session lifetime — default 12 hours, configurable per Base
• Re-auth triggers — high-risk actions (data export, config change) can require re-auth
• Device binding — sessions can be pinned to device fingerprints
• Kill switch — admin can revoke all active sessions instantly

Network-level zero-trust

• mTLS between all internal services
• Per-tenant data-plane isolation
• Egress controlled by explicit allowlist — agents can only reach configured destinations
• Web Application Firewall on ingress

Related

• Auth & RBAC — identity and role configuration
• Audit Log
• Encryption