The safest unauthorized action is the one that never reaches the upstream API. Detection after a send, share, or delete is valuable, but it cannot replace a decision point before the side effect.
Move authorization out of the prompt
Instructions such as 'always ask before sending' are behavior guidance, not an access-control boundary. Pakkawork receives the resolved contract and arguments and decides on the server whether to allow, hold, or block the action.
Evaluate the real request
- Confirm the API key maps to an active registered agent.
- Require an identified human principal and tenant.
- Validate every argument against the pinned contract.
- Compute effect and risk from the upstream operation.
- Check the Google connection, required scopes, host, quota, and rate bucket.
- Apply the locked floor before tenant-specific rules.
Make approval specific
An approver should see the exact recipient, resource, content summary, and destructive effect—not a generic tool name. The threshold is pinned on creation and requires distinct humans, preventing rule edits or duplicate clicks from bypassing quorum.
Record blocked attempts too
Denials reveal misconfigured agents, prompt injection attempts, missing scopes, and policy gaps. Pakkawork records decisions and reasons so blocked behavior contributes to better governance instead of disappearing from view.
Frequently asked
Can a client-side approval dialog secure an agent action?
It can improve UX, but the authoritative check must run on the server immediately before execution.
What happens when policy blocks an action?
Nothing is sent to Google. The action receives a blocked decision and reason, which is recorded for audit and policy review.