DOCS · GOVERNANCE · TECHNICAL REFERENCE

Action Authority & Approval Binding Protocol

A technical reference for how Createting evaluates configured agent actions, requests human approval when required, binds that approval to the requested operation, and retains decision evidence.

Protocol reference · draft 1.0 · 2026-09-19

1. Core model

Action + Resource + Effect + Context → ALLOW / ASK / DENY → bound approval where required → execution → retained evidence

This is a Createting runtime reference. It is not an industry standard, regulatory framework or deployment-readiness certification.

2. Action authority

Action authority answers whether a configured action may run in the current context. It is separate from how independently an agent reasons.

Resource scope

The policy input identifies the resource or capability being accessed. Current descriptors can carry a resource key alongside the action name, arguments and target-system context.

External consequence

The runtime distinguishes non-mutating work from side-effecting, external or sensitive actions during risk classification. Those signals can change whether the action proceeds or requires approval.

Policy decision

• ALLOW. The resolved policy permits the action to continue.
• ASK. Execution pauses for an operator approval before the action can resume.
• DENY. Execution is blocked. Disabled capabilities and explicit policy denial use hard-deny branches in the current implementation.

3. Approval binding

For ASK decisions, the runtime stores operation detail and a fingerprint derived from the action descriptor. When a run resumes, the approval is checked against tenant, agent, validity window and the requested descriptor before it can authorize continuation.

If the descriptor no longer matches—for example because the arguments or target context changed—the stored approval does not bind to the changed operation.

Decision context carried by the descriptor

• action type and action name;
• arguments and resolved resource key;
• non-mutating, side-effecting, external and sensitive signals;
• expected effect, data-access summary and target system where supplied;
• capability, explicit-deny and tool-autonomy inputs;
• additional metadata used by the configured runtime path.

4. Execution result and evidence

The policy gate records what it allowed, sent for approval or blocked. The current audit path persists a gateway event with decision context, policy-rule identifiers and the approval identifier when one exists.

Authorization evidence is not target-system success evidence.

A permitted action can still fail at execution time. Workflows that depend on an external effect need separate execution-result and target-state evidence before they describe that effect as complete.

5. Autonomy is not authority

Autonomy describes how independently an agent can progress through reasoning and execution. Authority describes which concrete actions it may perform. More autonomous reasoning does not silently expand action permission.

The inverse also matters: a deterministic Pathway can perform an explicitly configured and authorized write. A write does not by itself make the execution agentic.

6. Limitations and non-goals

• This protocol does not prove that every configured policy is complete or correct.
• It does not certify regulatory compliance or workload safety.
• It does not prove that an approved external effect succeeded.
• It does not replace target-system validation, security review or deployment-specific testing.

7. Related authority surfaces

Use the commercial governance page for the buyer-facing operating model, then follow the execution surfaces that apply to the workflow.