Constraint Vocabulary
Canonical definitions for all Provenance constraint tags. Constraints are declared in PROVENANCE.yml and enforced at dispatch time via gate().
Constraints are self-declared — a developer's public commitment to what their agent will never do. They are not automatically enforced at the infrastructure level. Platforms using gate() can require specific constraints before routing work, but ultimate enforcement depends on the agent's implementation. See the Trust page for an honest assessment of what declarations guarantee.
Will not process or store personally identifiable information.
The agent will not accept, process, log, store, or transmit data that identifies or could reasonably identify a natural person. This includes but is not limited to: full names, email addresses, phone numbers, physical addresses, government ID numbers, biometric data, IP addresses when linked to identity, health records, and financial account details.
- Input payloads must not contain PII — the agent is entitled to reject or redact such inputs.
- The agent must not write PII to any persistent store (database, file, log).
- The agent must not transmit PII to any third-party service.
- The agent is GDPR-compliant — compliance requires legal basis, data subject rights, and DPA agreements beyond a constraint declaration.
- The agent's underlying model was not trained on PII.
- The operator of the agent has configured infrastructure to enforce this at the network level.
Will not initiate, authorize, or record financial transactions.
The agent will not initiate, authorize, approve, record, or facilitate any movement of funds, including payments, transfers, refunds, currency exchanges, cryptocurrency transactions, or any operation that creates a financial obligation. The agent may read and report on financial data (balances, transaction history, invoices) but must not write or trigger any financial state change.
- The agent will not call payment APIs (Stripe, PayPal, bank APIs) in write mode.
- The agent will not submit purchase orders, invoices, or payment authorizations.
- The agent will not trade securities, tokens, or any financial instrument.
- The agent cannot read financial data — read-only access to balances or reports is permitted.
- The agent has no access to financial systems — it may have read access.
- The agent is SOC2 or PCI-DSS compliant.
Will not permanently delete data or resources.
The agent will not issue irreversible delete operations against any data store, file system, database, or infrastructure resource. This includes SQL DELETE without a soft-delete pattern, file system rm operations, cloud resource destruction (e.g. dropping databases, terminating instances), and API calls whose primary effect is permanent data removal.
- Destructive operations must be blocked, not just warned about.
- Soft deletes (marking records as deleted/archived) are permitted.
- The agent may propose deletions for human approval but must not execute them autonomously.
- The agent cannot modify data — updates and inserts are permitted.
- The agent cannot truncate a staging/test environment if explicitly scoped and reversible.
Will not act as or impersonate a specific human user.
The agent will not send messages, make API calls, sign documents, or take any action that presents itself as a specific named human individual — including composing emails or messages in a person's name without disclosure, using a human's credentials to authenticate, or claiming to be human in contexts where the counterparty would reasonably expect to be communicating with a person.
- Agent-authored messages must be disclosed as agent-generated or sent from an agent identity.
- The agent must not use OAuth tokens or session credentials belonging to a specific user without explicit delegation scope.
- The agent must not claim to be human when directly asked.
- The agent cannot draft content for a human to review and send themselves.
- The agent cannot operate on behalf of a user with explicit, scoped delegation.
Will not execute arbitrary code or shell commands.
The agent will not run arbitrary code, shell commands, scripts, or compiled binaries in any execution environment — including eval(), exec(), subprocess calls, container spawning, or remote code execution APIs. The agent may generate, review, or suggest code but must not run it.
- No shell access, no subprocess spawning, no eval.
- Code artifacts must be returned as text for human review, not executed.
- Sandboxed test runners with strictly bounded scope are a judgment call — disclose if used.
- The agent cannot use pre-defined, bounded tool calls (e.g. a search API or calculator).
- The agent cannot run its own internal reasoning — constraint applies to external execution.
Will not persist any input or output data beyond the current request.
The agent will not write any data from the current request — inputs, outputs, intermediate results, or metadata — to any persistent storage: databases, file systems, caches with TTL > session, logging pipelines, or third-party services. All processing is stateless and ephemeral.
- No database writes, no file writes, no cache writes that outlast the request.
- In-memory processing within a single request is permitted.
- Logging infrastructure must be configured to suppress or not receive this agent's payloads.
- The model itself is stateless — underlying model providers may log prompts per their own terms.
- The agent cannot read from persistent storage — read-only access is permitted.
Will not make outbound calls to external APIs or services.
The agent will not make outbound HTTP requests or network calls to any service outside the trust boundary defined by the dispatching platform. All processing uses only inputs provided in the job payload and internal tools explicitly whitelisted by the operator.
- No web browsing, no third-party API calls, no webhooks to external systems.
- Data retrieval must come from inputs or pre-loaded context, not live external calls.
- The agent cannot call internal APIs within the operator's own infrastructure if explicitly permitted.
- The agent cannot use the Provenance registry itself for identity verification.
Declaring constraints
Add constraints to your PROVENANCE.yml. Use only constraints your implementation actually enforces.
name: my-agent version: 1.0.0 capabilities: - write:code - read:files constraints: - no:pii - no:financial:transact - no:store:data
Gating on constraints
Platforms can require constraints before routing work. The gate() call returns allowed: false if the agent has not declared the required constraints.
import { Provenance } from 'provenance-protocol';
const provenance = new Provenance();
const result = await provenance.gate(agentId, {
requireConstraints: ['no:pii', 'no:store:data'],
requireClean: true,
});
if (!result.allowed) throw new Error(result.reason);
// safe to dispatch sensitive data