To temporarily disable an AI agent’s access to a configured API, pause that connection at the gateway that sends its requests. In ActionDock, the signed-in workspace owner selects Pause in Connections. The connection keeps its configuration and stored credential, but new reads, writes, Test GET requests, and owner approval are blocked while it is paused. Other connections remain available. The pause affects every agent using that connection, not just the agent under investigation.
This is scoped isolation, not a global agent kill switch. Requests already past the final state check may finish, the provider credential is not revoked, and direct browser, shell, or provider access is not blocked. Resume is a new access decision—not permission to reuse old write approvals or replay uncertain operations.
When a reversible pause is useful
Use a connection pause while investigating unexpected requests, maintaining an API, narrowing an overly broad policy, or validating an agent-framework fix. It lets you preserve setup while deciding whether the route should be available again. Asking the model to stop is not the same as enforcing that decision in the component that can send the request.
Recent framework changes illustrate the need for an operational stop control. Agno’s v3.1.2 release, published October 8, 2026 (UTC), fixed reuse of an earlier approval record for a second approval-required tool call in the same run. That is a documented software fix, not evidence of a customer data-loss incident. If a relevant defect affects your stack, patch and test it; pausing a routed connection can limit access during that work, but does not repair the framework or control its direct tools.
The general principle is to enforce access outside the model. OWASP’s authorization guidance recommends checking permissions on every request. ActionDock’s current connection-state checks apply at submission, approval, and execution, including a final check before dispatch after asynchronous preparation.
Choose the control with the right scope
| Control | What it addresses | What it does not establish |
|---|---|---|
| Pause an ActionDock connection | Temporarily block routed API access through one connection while keeping its setup | That already-sent work stopped, or the provider credential lost its permissions |
| Revoke one queued approval | Close one approved write as rejected if the worker has not claimed it |
That future requests through the connection are blocked |
| Revoke or rotate a provider credential | Address that credential’s access at the provider, under the provider’s rules | That existing changes were undone, or every alternate access path was removed |
If only one approved proposal is obsolete, follow the queued-write cancellation procedure. If the route itself needs review, pause the connection. If a credential may be compromised, treat provider-side remediation as a separate incident-response task; a reversible gateway pause is not a substitute.
1. Pause the affected connection and confirm its state
In Connections, identify the connection by its name, base URL, and allowed methods. Select Pause, then confirm the row says Paused. The configuration and credential remain stored; Edit remains available, while Test GET, when available for the connection, is disabled. Paused connections still count toward the plan’s connection limit. Sandbox connections cannot be paused.
The owner-session API is POST /v1/dashboard/connections/{id}/state. To pause, send:
{"enabled":false}The endpoint requires the owning workspace’s dashboard session and a same-origin Origin header. It returns the updated connection; it does not expose the stored credential. An agent API key cannot toggle state, and no MCP tool can resume the connection. Agents can observe enabled: false through GET /v1/connections or MCP list_connections.
If the response is lost or the dashboard cannot refresh, reload and check the actual state rather than assuming either success or failure. Repeating the current state is a no-op: it does not increment the version again or create another state-change event. Each real transition records an owner-attributed integration.paused or integration.resumed event.
2. Inspect outstanding jobs; pause is not bulk cancellation
Pausing a connection does not immediately rewrite every job attached to it. Read the affected jobs in Workflows and jobs, or use authenticated job reads. Keep their original IDs and submission keys for investigation.
An existing awaiting_approval write keeps its original preview and reservation. Trying to approve it while paused returns 409 integration_paused. Pausing does not automatically reject that proposal or release its reservation; explicitly reject an obsolete pending write.
An approved queued write is not parked for later replay. If execution detects the pause or a stale connection version before dispatch, the job becomes failed, retains its preview, and releases its processing reservation. The pause does not synchronously clear the queue, so inspect the resulting job state rather than assuming every row changed immediately.
A running label alone does not tell you which side of the final dispatch check the request reached. A request still being prepared can be blocked; one already past that check may be sent and finish successfully. If a write’s response is lost after dispatch, the outcome can remain execution_unknown. Neither the Paused badge nor a state-change timestamp proves that no external effect occurred.
For an unknown outcome, use the read-first reconciliation procedure. The paused connection also blocks new integration.fetch requests, so an owner may need a separate authorized read-only provider console or investigation path. Do not give the agent a direct write credential just to bypass the pause. Preserve the original execution record and provider evidence as described in the API audit-trail guide.
3. Review the route and any credential exposure
While the connection is paused, review its destination, method list, path prefixes, and any owner-authored runtime policy. Ordinary configuration edits preserve the pause state, including credential changes. The state endpoint itself does not delete or rotate the secret.
If a credential was exposed, follow the provider’s compromise procedure and update every legitimate consumer. For example, GitHub’s credential-security guidance calls for a replacement credential, updates wherever the credential is stored or used, and deletion of the compromised old credential. Use the affected provider’s actual rules rather than assuming all tokens have identical revocation behavior.
Also inventory bypass routes: another provider key, an authenticated browser, a native MCP server, or shell access to a credential-bearing host. Those paths are outside ActionDock. The server-held credential guide explains why hiding a key from model context is not enough if another tool still has direct access.
These are general operator responsibilities. ActionDock does not provision or automatically rotate provider credentials, patch your agent framework, or shut down other tools.
4. Resume with a new write proposal, not an old approval
Resume only after the investigation or maintenance work justifies reopening the route. Select Resume, or use the same owner endpoint with {"enabled":true}. Confirm Active, perform an appropriate read or Test GET, and inspect current provider state before proposing a change.
Every actual pause and resume increments the connection version. For example, a write reviewed at version 7 remains bound to version 7; pausing moves the connection to version 8, and resuming moves it to version 9. Even with the same URL, policy, and credential, the old write proposal is stale. Approval after resume returns 409 integration_approval_stale rather than reviving it.
Reject an obsolete pending proposal, then submit a genuinely new write with a new idempotency key and obtain separate owner approval. Reusing the original key with the same input returns the historical job—even while paused—not a fresh proposal. Resume never reruns a failed or execution_unknown job. Reconcile an unknown provider outcome before deciding whether any replacement write is safe.
This version rule applies to write proposals and approvals. Do not assume every read job queued before the pause is permanently invalidated after resume; reads have no write-approval snapshot.
A pause-and-resume checklist
- Identify the affected connection, not just the agent or workflow name.
- Confirm Paused or
enabled: false; resolve any uncertain response. - Inspect pending, queued, and running jobs separately.
- Verify provider state for requests that may already have been sent.
- Handle leaked credentials and alternate access paths outside the gateway.
- Review the configuration while it remains paused.
- Resume deliberately, then read current state or test the connection.
- Use a fresh proposal, key, and owner approval for a replacement write.
Start with the connection contract and approved API workflow. A safe pause preserves configuration while denying the selected route; a safe resume preserves history while requiring a new decision about the next write.