> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reset the operator kill switch

> Lets authorization and approval requests through again.



## OpenAPI

````yaml openapi.bundled.yaml POST /kill-switch/reset
openapi: 3.1.0
info:
  title: Parmana API
  version: 1.0.0
  description: >
    Parmana sits between an AI agent and the systems it acts on. An agent sends
    a Business Transaction: who

    authorized it, what action it wants, and the facts that justify it. Parmana
    evaluates the policy bound to

    the action, checks any signed human approval the policy requires, releases
    the action to the connector

    only if the policy approves, and returns a signed Execution Trust Record
    anyone can verify.


    **Authentication.** Send `Authorization: Bearer <key>` on every request. The
    only routes that need no key

    are the probes, the documents and the independent verification routes: `GET
    /health`, `GET /ready`,

    `GET /openapi.yaml`, `GET /openapi.json`, `GET /api-manifest.json`, `GET
    /documentation`,

    `GET /reference`, `GET /parmana-handbook.pdf`, `GET
    /handbook/download-leads`,

    `POST /handbook/download-leads`, `POST /refusal/verify`, `POST
    /execution-intents/verify`,

    `POST /audit/verify`, `GET /keys/{keyId}` and `GET /.well-known/jwks.json`.
    A missing or unknown key

    returns `401` before anything else runs. The server holds only a hash of
    each key. See

    [Authentication](/api-reference/authentication).


    **Two kinds of key.** An agent or service key may invoke only the
    capabilities listed on it. A human key

    (`credentialHolderType: USER`) is required for governance: proposing and
    approving policies, approvers

    and external connectors, and repairing Execution Intents. Approving or
    rejecting a change also needs a

    step up authorization signed with the checker's own step up key, and the
    checker must not be the

    person who proposed it.


    **Ownership.** Every lookup by `businessTransactionId` is scoped to the key
    that submitted the

    transaction. A transaction submitted by another key returns the same `404`
    as one that does not exist.


    **Try it live.** The first server below is the public sandbox,
    `https://parmana-sandbox.vercel.app`: the same

    code as production with its own database, keys and demo approver, whose one
    action, `sandbox:receipt`,

    acts on nothing. Every "Try it" panel calls it with the published demo key
    prefilled. The demo key may

    invoke only `sandbox:receipt`, so other capabilities return `403` and
    governance routes return

    `403 NON_HUMAN_CALLER_DENIED`. Everything sent to the sandbox is visible to
    every visitor. See

    [Playground](/playground). Production needs a key issued by its operator.


    **Start here:** the [Playground](/playground) (no install), the
    [Quickstart](/quickstart), then [Integrate Parmana](/agents/integrate) for
    agents

    and [Connect any external system](/guides/connect-any-external-system) for
    your own endpoint.
  contact:
    name: Parmana Systems
    email: founder@parmanasystems.com
  license:
    name: Proprietary, source-available for evaluation only, see LICENSE
    url: https://github.com/pavancharak/parmana/blob/main/LICENSE
servers:
  - url: https://parmana-sandbox.vercel.app
    description: >-
      Public sandbox (the docs playground). Same code as production, demo data
      only, acts on nothing. Demo key prefilled.
  - url: https://parmana-api-real.vercel.app
    description: Production. Needs a key issued by the operator.
  - url: http://localhost:3000
    description: Local (packages/api, PORT env var, default 3000)
security:
  - bearerAuth: []
tags:
  - name: Execution
    description: >-
      Executes a Business Transaction through the complete Execution Trust
      pipeline
  - name: Transactions
    description: Business Transaction creation and retrieval
  - name: Verification
    description: Deterministic verification of an Execution Trust Record
  - name: Receipts
    description: Cryptographically signed Execution Trust Receipts
  - name: Trust Records
    description: Execution Trust Record retrieval
  - name: Replay
    description: Deterministic replay of a recorded Execution Trust Record
  - name: Policies
    description: Policy existence/readability check
  - name: Policy Governance
    description: Maker-checker proposal, listing, approval, and rejection of policy changes
  - name: Approvers
    description: Maker-checker for the keys trusted to sign approvals, without a deploy
  - name: External Connectors
    description: >-
      Maker-checker for binding a capability to an operator's HTTPS endpoint and
      its policy, without a deploy (ADR-0013)
  - name: Business Signal Sources
    description: >-
      Maker-checker for the business systems Parmana asks for the facts a policy
      needs, without a deploy (RFC-0023)
  - name: Authority Grants
    description: >-
      Maker-checker for which agent may have which action decided, within which
      limits, until when (RFC-0023)
  - name: Sandbox
    description: >-
      Routes that exist only on the public sandbox (ADR-0014), for trying
      Parmana from a browser
  - name: Kill Switch
    description: >-
      Operator kill switch (ADR-0017). Trip and reset need the operator
      capabilities, and probe results need the probe capability; status is open
      to any authenticated caller
  - name: Refusal Records
    description: >-
      Durable, signed evidence that a policy decision rejected a transaction
      (RFC-0021)
  - name: Execution Intents
    description: >-
      A signed statement, stored before an action is released, of exactly what
      is about to be released, plus the operator tools to find and repair a
      released action that has no signed Trust Record (ADR-0012)
  - name: Audit
    description: >-
      Signed caller-authentication audit events, independently
      third-party-verifiable
  - name: System
    description: Operational endpoints
paths:
  /kill-switch/reset:
    post:
      tags:
        - Kill Switch
      summary: Reset the operator kill switch
      description: >
        Lets authorization and approval requests through again. Needs the
        `kill-switch:reset` capability on the key.

        In production a reset takes two different operators (ADR-0017 decision
        1). The first request answers 202 and

        holds the reset as pending. A second operator's request completes it and
        answers 200. The same operator

        cannot confirm their own request (409). A trip cancels a pending reset.
      operationId: resetKillSwitch
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - reason
              properties:
                reason:
                  type: string
                  minLength: 1
            example:
              reason: reviewed, safe
      responses:
        '200':
          description: Reset complete. Returns the outcome and the state.
          content:
            application/json:
              schema:
                type: object
              example:
                outcome: reset
                state:
                  active: false
                  version: 3
                  trippedBy: operator-a
                  trippedAt: '2026-10-20T14:00:41.256Z'
                  tripReason: suspicious refunds
                  resetRequestedBy: operator-a
                  resetBy: operator-b
                  resetAt: '2026-10-20T14:00:41.276Z'
                  resetReason: confirmed
        '202':
          description: The reset is pending. A second, different operator must confirm it.
          content:
            application/json:
              schema:
                type: object
              example:
                outcome: pending
                state:
                  active: true
                  version: 2
                  trippedBy: operator-a
                  trippedAt: '2026-10-20T14:00:41.256Z'
                  tripReason: suspicious refunds
                  pendingResetBy: operator-a
                  pendingResetAt: '2026-10-20T14:00:41.271Z'
                  pendingResetReason: reviewed, safe
        '400':
          description: The reason is missing.
          content:
            application/json:
              schema:
                type: object
              example:
                error: reason is required.
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          description: The key lacks the kill-switch:reset capability.
          content:
            application/json:
              schema:
                type: object
              example:
                error: CAPABILITY_NOT_ALLOWED
                message: This key does not hold the kill-switch:reset capability.
        '409':
          description: >-
            The same operator asked for this reset before. A second operator
            must confirm it.
          content:
            application/json:
              schema:
                type: object
              example:
                error: SAME_OPERATOR_CANNOT_CONFIRM_RESET
                message: A second operator must confirm this reset.
      x-codeSamples:
        - lang: bash
          label: cURL
          source: |-
            curl -X POST https://your-parmana-server/kill-switch/reset \
              -H "Authorization: Bearer $PARMANA_API_KEY" \
              -H "Content-Type: application/json" \
              -d '{"reason": "reviewed, safe"}'
        - lang: typescript
          label: TypeScript
          source: >-
            const response = await
            fetch("https://your-parmana-server/kill-switch/reset", {
              method: "POST",
              headers: {
                Authorization: `Bearer ${process.env.PARMANA_API_KEY ?? ""}`,
                "Content-Type": "application/json",
              },
              body: JSON.stringify({ reason: "reviewed, safe" }),
            });


            console.log(await response.json());
        - lang: python
          label: Python
          source: |-
            import json
            import os
            import urllib.request

            request = urllib.request.Request(
                "https://your-parmana-server/kill-switch/reset",
                data=json.dumps({"reason": "reviewed, safe"}).encode(),
                headers={
                    "Authorization": f"Bearer {os.environ.get('PARMANA_API_KEY', '')}",
                    "Content-Type": "application/json",
                },
                method="POST",
            )

            with urllib.request.urlopen(request) as response:
                print(json.loads(response.read()))
components:
  responses:
    Unauthorized:
      description: >-
        The `Authorization` header is missing, is not a bearer key, or names a
        key the server does not know. Nothing ran. Send a valid key.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/error.schema'
          examples:
            authRequired:
              summary: Real captured response, missing or invalid Authorization header
              value:
                error: authentication required
  schemas:
    error.schema:
      title: Error Response
      description: >-
        Shared error envelope produced by
        packages/api/src/middleware/error-handler.ts and by every route's inline
        validation checks. error is always a plain human-readable string (never
        a nested object). code is present only when the failure was a
        RuntimeError subclass reaching the centralized error handler
        (VerificationFailedError, ReceiptGenerationError, or an uncategorized
        RuntimeError); it is absent from every inline route-level check
        (businessTransactionId format/required checks) and from
        BusinessTransactionValidationError, PolicyValidationError,
        SignalValidationError, PolicyNotFoundError,
        DuplicateBusinessTransactionError, and the generic 500 fallback. POST
        /policies/validate does NOT use this envelope at all. See its own
        response schema. For the triggering condition and recommended caller
        action behind any specific error/code/status combination, see the Error
        catalog at /api-reference/error-catalog.
      type: object
      additionalProperties: false
      required:
        - error
      properties:
        error:
          type: string
          description: Human-readable error message.
        code:
          type: string
          description: >-
            Stable machine-readable error code. Only present for errors that
            reach the handler as a RuntimeError.
          examples:
            - RUNTIME_ERROR
            - VERIFICATION_FAILED
            - RECEIPT_GENERATION_FAILED
            - POLICY_DENIED
            - CAPABILITY_NOT_ALLOWED
            - RATE_LIMITED
            - AUDIT_UNAVAILABLE
            - SIGNING_UNAVAILABLE
            - CONNECTOR_NOT_REGISTERED
            - EXECUTION_RECORD_INCOMPLETE
            - EXECUTION_INTENT_UNAVAILABLE
            - EXECUTION_INTENT_RESULT_NOT_RECORDED
            - EXECUTION_INTENT_NOT_FOUND
            - EXECUTION_INTENTS_NOT_ENABLED
            - EXECUTION_INTENT_NOT_RESOLVABLE
            - EXECUTION_INTENT_RESOLUTION_INVALID
            - NON_HUMAN_CALLER_DENIED
            - EXECUTION_OUTCOME_UNKNOWN
            - AUTHORIZATION_NO_LONGER_VALID
        executionStatus:
          type: string
          enum:
            - EXECUTION_UNKNOWN
            - NOT_EXECUTED
          description: >-
            RFC-0023 phase 4. EXECUTION_UNKNOWN with EXECUTION_OUTCOME_UNKNOWN:
            the action was released and the call failed, so whether it ran is
            unknown; never reported as failed, and the Execution Intent stays
            ERRORED until a person resolves it. NOT_EXECUTED with
            AUTHORIZATION_NO_LONGER_VALID: the release was refused because a
            business condition or the authority grant it rested on no longer
            held, and nothing was sent.
      examples:
        - error: businessTransactionId must be a valid UUID.
        - error: >-
            Business Transaction 'eed2a972-1bf5-4166-8472-761f76fbf1b2' already
            exists.
        - error: >-
            Execution rejected: Vendor payment rejected because the assessed
            payment risk exceeds the maximum permitted threshold.
          code: RUNTIME_ERROR
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      x-default: <your-api-key>
      description: >
        Caller API key issued by scripts/generate-api-key.ts. Sent as
        Authorization: Bearer <key>. Verified against a stored SHA-256 hash in
        constant time by packages/api/src/auth/StaticKeyAuthenticator.ts.
        Required on every route not listed as exempt in this document's
        top-level description. See /api-reference/authentication.

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.