Policy & approvals

Every tool or action is evaluated at the call: custom toolId or pack action.

• ALLOW: may proceed (still logged / redacted).
• DENY: blocked. No silent bypass.
• REQUIRE_APPROVE: waits in the Approvals queue until a person decides.

Wrap evaluates and may open a ticket. It never runs the write. POST /api/v1/kya/tools/invoke (CLI: kya invoke) authorizes on the plane after Allow or APPROVED, consumes once, and still does not execute the customer function here. Keep processor secrets off the agent. A registered executor or optional edge hop runs only after that receipt.

Session risk from Observe or guardrails can only raise severity (for example ALLOW becomes REQUIRE_APPROVE). It cannot approve a high-stakes action on its own.

Dual plane: same verdicts on host=ide and host=runtime. Shield is the sole PEP. An edge or collab UI click does not replace ApprovalRequest=APPROVED.

Workspace modes (owner/admin): human mint (allow + trail, break-glass, require approve) and HIGH-risk shrink (operator, auto to Build, ask a person). Console: /app/kya/policy.

Session clearance can DENY with reason SESSION_CLEARED when the tool is above Read / Build / Deploy. See session clearance.

Operator UI: /app/kya/approvals and /app/kya/policy.