Pakkawork

Provider-agnostic pipeline

Supported agent actions move through six enforced stages.

Pakkawork uses provider-agnostic control-plane architecture, with Google Workspace as the first provider family. MCP and REST requests share the same policy and evidence path when their contracts support execution.

Connect Google WorkspaceInspect every stage
  1. 01

    Connect Google OAuth

  2. 02

    Register identities

  3. 03

    Ask over MCP or REST

  4. 04

    Assess and apply policy

  5. 05

    Reach human quorum

  6. 06Recorded

    Execute and record

Supported request in · signed provider result outSame gate over MCP and REST

How Pakkawork works

Six enforced steps

MCP 2025-06-18 JSON-RPC · REST ingress · Same server-side gate

Any request in. Governed outcome out.

Connect Google Workspace and register identities once. After that, each supported action follows the same contract, policy, approval, execution, and evidence path.

  1. 01
    Connect Google OAuth

    Connect Google with minimal access

    Google Workspace is Pakkawork's first provider family. The public flow uses Pakkawork's platform OAuth client and requests only the five executable apps' minimal scopes; a workspace administrator may optionally configure a tenant-owned client. Credentials and quota stay tenant-isolated, while host allowlists and SSRF containment define where supported execution may go.

    Gmail send-only access never reads the mailbox; full restricted-scope modes remain disabled until separate Google verification.

  2. 02
    Register identities

    Register the agent and its human operator

    Register each agent under a named human operator, set its risk ceiling, and issue an API key shown once and stored only as a hash. Provider secrets remain under AES-256-GCM envelope encryption.

    Every request carries accountable agent and operator identities before policy runs.

  3. 03
    Ask over MCP or REST

    Resolve the request against the contract catalogue

    Requests arrive over MCP 2025-06-18 JSON-RPC or REST and resolve against 555 immutable contracts. Eight progressive-disclosure MCP tools keep discovery bounded. Only supported contracts in the five executable apps proceed to quota preflight and execution.

    The other 11 wired apps expose generated contract metadata only; catalogue presence is not execution support.

  4. 04
    Assess and apply policy

    Derive risk from the API shape and real arguments

    Pakkawork evaluates the observed API shape and the actual arguments, then applies deterministic policy on the server before the model and outside prompts. Contract versions, hashes, and descriptions remain pinned for the decision.

    A risky action returns pending approval, and no provider action executes while it waits.

  5. 05
    Reach human quorum

    Hold critical actions for distinct approvers

    Approval happens out of band. Critical actions require 2 distinct approvers, and the required threshold is pinned while the request is in flight so the decision boundary cannot move mid-review.

    An agent cannot approve its own action, and pending means no provider call has run.

  6. 06
    Execute and record

    Execute supported contracts, then preserve the result

    Supported contracts execute with host allowlists, SSRF containment, and bounded jittered backoff. The provider result joins an append-only sha256 chain signed with Ed25519. A read-back runs only for the 22 contracts with implemented post-conditions, and rollback requires contract-defined compensation.

    Deterministic model-free replay sends supported steps through the same gate; generated catalogue-only contracts never execute.

The entire gate at a glance

Request to evidence

Pinned

In-flight approval threshold

2

Distinct critical approvers

Ed25519

Signed sha256 ledger

From supported request to signed result, with checks and rollback only where defined.

Govern your first action