Trace the decision before you trust the action.

Pakkawork is a provider-agnostic AI governance control plane between an agent and the APIs it calls. It evaluates deterministic policy before execution, pauses actions that need people, executes with isolated per-tenant credentials, verifies outcomes where the contract supports real read-back, and appends the control trail to signed evidence. It works over MCP or REST rather than belonging to one model, framework, or provider.

Yes. The gate is in the execution path, outside the agent framework and prompt. An agent can reach it through MCP, while application code can use REST. Both transports evaluate the same contract, arguments, policy, approval state, execution controls, and evidence rules, so switching a framework or model does not create a bypass.

A warrant is the technical record for one gated action. It binds the selected tool contract and hash to the real arguments, computed risk, pinned approval threshold, human decisions, execution outcome, verification result, and any pre-captured inverse. Reading it shows why the action was held or allowed and what happened after that decision.

Policy runs deterministically on the server before execution and is not part of the prompt. Risk is derived from the API shape and the actual arguments, not from an agent's explanation. The required approval threshold is then pinned to the request, preventing later catalogue or policy changes from silently weakening that decision.

Not when it acts through Pakkawork. Approval state is enforced in the database, outside the conversation, and a pending action executes nothing. Rewording the request, retrying it, changing models, or moving between MCP and REST still reaches the same deterministic gate and the same pinned approval requirement.

The proposed call becomes pending before any provider request is made. A person reviews the decoded arguments and approves or refuses out of band. Critical actions require 2 distinct approvers, with distinctness and quorum enforced atomically in the database. The action runs only after the pinned threshold has been satisfied.

An accepted provider response is not automatically treated as proof. For the 22 verified/read-back contracts, Pakkawork reads the resulting state from the real API and checks the expected postcondition. A mismatch is recorded as a verification failure even if the provider accepted the request. The 533 generated/unchecked contracts do not claim that read-back guarantee.

Where an action has a meaningful inverse, Pakkawork captures that inverse before execution instead of reconstructing it afterwards. A failed call, failed verification, or authorized recovery request can apply the recorded inverse through the gate, and the recovery becomes another signed ledger event. Actions without a safe inverse are identified rather than presented as reversible.

Replay runs a recorded sequence from its stored contracts and arguments with no model in the loop. Every step still passes through current policy and any required human gate. That makes replay useful for reproducing an incident or checking a prior decision without giving the recorded sequence a privileged path around governance.

Serious events enter an incident register and can move through the incident reporting workflow. Durable jobs preserve work across process interruptions, atomic RPC transitions keep state changes consistent, triggers emit heartbeats even when no work is found, and failed runs retain their metadata in a dead-letter queue so silence is not mistaken for success.

The contract pipeline and execution boundary are provider-neutral, so they are designed for any API that can be described and connected safely. Live today means 555 contracts across 16 provider apps: 22 verified with real read-back and 533 generated/unchecked. The first provider family happens to be 16 Google apps. Scaling past 2,000 APIs is the built pipeline roadmap, not a claim that 2,000 integrations are live.

Choose the transport that fits the caller. MCP exposes 8 tools for catalogue discovery, argument preparation, governed execution, approval state, and evidence. REST exposes the same control plane to application code. Policy, approval, credentials, execution containment, verification, and ledger behavior are identical on both.

Each tenant uses its own OAuth app and requests a minimal scope bundle for the actions it intends to run. The authorization handshake uses PKCE, and OAuth state is single-use and consumed atomically in Postgres. Broader scopes must be chosen deliberately rather than inherited from a shared provider connection.

Provider tokens use AES-256-GCM envelope encryption with a per-secret data key wrapped by a key-encryption key. They are never returned to the browser or exposed to MCP clients. Agent API keys are shown once and stored only as sha256 hashes. Browser sessions use Supabase Auth rather than sharing agent credentials.

Execution is restricted to a strict upstream host allowlist. Redirects are handled manually, and credentials are stripped before any cross-origin redirect is followed. Immediately before execution, Pakkawork re-checks the selected contract hash; if the contract changed after approval, the call is refused instead of running different behavior.

The ledger is append-only, signed, hash-chained, and serialized per tenant. It records the contract and arguments the control plane saw, the deterministic decision, human approvals, execution result, verification outcome, and recovery events. It proves what Pakkawork recorded about its own controls; it is governance evidence, not an external certification.

Limited Use redaction keeps message bodies, file contents, and cell values out of persisted evidence and model context. Pakkawork retains the metadata required to authorize and prove the governed action. Signed evidence retention is 7 days on Developer, 90 days on Team, and custom on Enterprise.

Row-level security applies to all tenant tables. Privileged service access is limited to narrow server-only repositories, while ledger and durable-job transitions are tenant-scoped and atomic. One workspace cannot read, alter, delete, or interleave another workspace's governance evidence through the application path.

No. Pakkawork implements controls, records decisions, and produces governance evidence that an organization can use in its own review and attestations. It does not certify the organization, replace independent assurance, or turn a signed ledger into a compliance result. Claims should stay limited to the controls and evidence actually present.

Developer is free and includes one workspace, one provider connection, full catalogue search, a single-approver gate, and 7 days of signed evidence. Team includes all 16 wired apps, a 2-person quorum for critical actions, deterministic replay, heartbeat and dead-letter reliability, and 90 days of evidence. Enterprise adds SSO, custom retention, private deployment, governance attestations, an incident reporting workflow, and priority review. No card is required to start.