Product

AccordsConnectors

The outbound permission layer for agentic workflows.

You decide exactly which systems, services, and workflows your customers can reach through an agent. Agents operate inside that surface. Receipts prove what happened.

Connectors are the opposite of a blank-check API key. Every action has a schema, a policy, a budget, and a receipt. The reasoning layer of an agent decides what should happen. The connector decides what is allowed to happen.

The protocol underneath is CLP — the ContractLane Protocol — and it treats agent execution the way an operating system treats user-space programs. Schemas, permissions, resource quotas, signed audit trails. Five pillars keep agents useful without making them dangerous.

How a connector actually works

Agents hold receipts, not secrets.

Every action an agent takes through a connector follows the same four-step handshake. No raw credentials cross the agent boundary. No scope the user didn't authorize.
{action, intent}policy + budgetephemeral scopesigned receiptAGENTrequests actionCONNECTORverifies policyVAULTreleases credentialSERVICEexecutes + receipts
The five pillars

What a connector actually enforces.

01

Typed connectors.

Every agent action passes through a structured connector. The connector defines the schema, the allowed parameters, and the policy constraints. The agent requests an operation — it doesn't construct a raw API call.

02

Secret isolation.

Agents never see credentials. The secret stays inside the execution boundary; the action uses it on the agent's behalf. Credential leakage is not mitigated — it is eliminated.

03

Secure document boundary.

Documents are referenced by role or type, never transferred as raw files. Connectors access only the document types the policy allows. Every access is logged in a deterministic receipt.

04

Economic ledger.

Cost reservations happen before execution. Budget check, reserve, execute — or deny. Runaway cloud bills, unintended transactions, and loop-triggered spend all stop at the ledger.

05

Deterministic receipts.

Every action emits a cryptographic receipt. Canonical request hash, policy decision, execution result, cost accounting. Verifiable without trusting the system that generated it.

What it looks like in code

Bounded by policy, signed by receipt.

A refund connector with a policy ceiling and a signed receipt the agent could never fake. The agent requested an action. The connector did the rest.
example.ts
1import { Connector, policy } from '@accords/connectors';
2
3const refunds = new Connector({
4 id: 'stripe.refunds',
5 policy: policy({
6 maxAmountUsd: 500,
7 requireOriginalCharge: true,
8 dailyLimit: 20,
9 }),
10});
11
12// Agent never sees the Stripe API key.
13const { receipt } = await refunds.execute({
14 action: 'refund',
15 chargeId: 'ch_3Po4...',
16 amountUsd: 42.00,
17 reason: 'order.item-missing',
18});
19
20// receipt is cryptographically signed and
21// independently verifiable by any counterparty.
22console.log(receipt.id);