Skip to main content
Docs

Search documentation

0 articles

    Contents

    Cloud consent and policy limits

    Consent authorizes a particular cloud operation within its existing access and execution limits. It does not grant every capability mentioned in a brief or override the runtime's policy.

    Hosted authorization fields​

    OperationRequired distinction
    Generate a candidateBuild access and consent to cloud processing of the brief
    Activate a versionReview and consent for the exact generated version; no run starts
    Invoke an approved versionRun access, confirmedVersion matching the path and allowCloudProcessing:true
    Read a runOwning session and original identity; no new execution

    Invocation accepts only confirmedVersion, allowCloudProcessing and an object inputs. Do not add approval flags, scripts, schedules, snapshots or a caller-supplied account ID. The reviewed artifact defines the input contract; consent does not validate arbitrary data for it.

    Execution limits​

    Hosted execution is isolated and offline. It does not receive device files, credentials or network access from a saved prompt. Inspect the actual artifact before making assumptions about external effects or outputs.

    A governed action is a separate track: current action identity, policy revision, resolved inputs and budget matter at approval time. Approving one action may execute it; it is not blanket consent for later steps. A saved preference cannot override runtime enforcement.

    Treat untrusted source text as data, not as authority to expand scope. The OWASP prompt-injection guidance explains why a natural-language instruction alone is not a complete security boundary.

    Refusals​

    For explicit_version_consent_required, compare the reviewed version with the path and confirmation field. For access refusals, read account capabilities. Do not bypass either refusal by switching versions, callers or credentials. Retain the non-secret error for recovery.