Mechanism over claims
We explain the enforcement path and publish only implementation-backed product facts.
Why Pakkawork exists
Agents can act in seconds. Control has to stay in the path.
Pakkawork uses provider-agnostic control-plane architecture, with Google Workspace as the first provider family: deterministic policy, human approval, contained supported execution, read-back on 22 verified contracts, contract-specific recovery, and signed evidence.
Case PW-001 · control boundary
One action, complete evidence
- 01Request
An identified agent asks to call a versioned tool over MCP or REST.
- 02Decision
Pakkawork computes risk, applies policy, and obtains human approval when required.
- 03Evidence
Verified contracts read state back; supported execution and recovery events enter the signed ledger.
The design premise
Why the control plane belongs outside the agent
An agent can turn natural language into a destructive API call almost instantly. A prompt can guide that choice, but it cannot serve as an authorization boundary that the same agent is unable to bypass.
Pakkawork moves enforcement into the supported execution path. Each runnable request resolves to an immutable, content-addressed contract; risk is computed from the API shape and real arguments; deterministic policy decides whether to allow, approve, or block the action.
After an allowed call runs, verified contracts read provider state back and report a mismatch as failure rather than false success. Generated contracts remain explicitly unchecked. Where a safe inverse exists, it is captured before execution, and the complete sequence enters a signed, hash-chained ledger.
"A successful HTTP response is not proof that the intended state changed. Read it back, verify it, and preserve the evidence."
P
Pakkawork
AI governance control plane
Provider-neutral · MCP and REST
"Govern the action where intent becomes execution."
The first provider family happens to be 16 Google apps. The policy gate, contract pipeline, ledger, MCP surface, and REST surface remain provider-neutral.
admin@pakkawork.comOur mission
Make agent autonomy governable.
Give teams one enforceable path from supported agent intent to provider result, with identity, policy, approval, signed evidence, and contract-specific verification and recovery.
Enforcement over prompts
Policy and approval run on the server in the execution path, not inside agent instructions.
Evidence over status codes
Verified contracts read provider state back, unchecked contracts stay labeled, and signed records preserve what happened.
Product facts we can state plainly.
555
live API contracts
22
verified contracts with real read-back
8
MCP tools over the same REST control plane
The remaining 533 contracts are generated/unchecked. There are 16 provider apps wired today. Scaling past 2,000 APIs is the built pipeline roadmap, not a live count.