---
{
  "id": "platform.webhook.permissions-and-safety",
  "topic": "webhook",
  "title": "Webhook permissions and safety boundaries",
  "locale": "en",
  "version": "2026-08-09.1",
  "summary": "Webhook management is owner-scoped, target access is rechecked, secrets and payloads are redacted, and risky actions keep registry confirmation.",
  "content": "All webhook actions derive identity from `ActionContext::owner_id`; a model-supplied user id cannot widen scope. They also require an explicit per-webhook Agent grant capped by both the Agent owner and webhook owner. `read` permits list, get, fire-event history, and payload lookup; `write` also permits update, cancel, and rotate. Missing, revoked, read-only-for-write, and cross-owner resources all return `resource_not_found`. Target execution separately checks permission to the referenced conversation or board and rechecks the captured target configuration at dispatch time.\n\nPlaintext signing secrets are display-once for create and rotation. They are removed from idempotency replay and covered by result redaction. Payload and filtered header fields are also redacted from persisted action results, are owner-only, expire after 24 hours, and have an audited 30-requests-per-minute access path.\n\nRegistry policy remains authoritative. Creating a webhook requires the owner-managed `canCreateWebhook` capability; the new webhook records its creating Agent and grants that Agent write access atomically. The grandfather migration granted existing Webhooks only to active external Agents; platform Agents received zero grants and may see an empty list until the owner shares each Webhook. An Agent may create a webhook-backed Trigger only when it can read that webhook. Rotation and cancellation require user confirmation and strict drift protection. Create, update, rotate, cancel, and payload-detail actions are not allowed in public conversations; read-only list/get/history actions may be available there, subject to the explicit grant.\n\nInbound delivery itself authenticates with HMAC, timestamp tolerance, and nonce replay protection, and enforces payload-size, rate, enabled, status, and expiry gates. Platform Knowledge can explain these rules but cannot add an action, bypass confirmation, reveal a secret, or grant access to a target resource.\n",
  "aliases": [
    "webhook permissions",
    "owner only",
    "different user payload",
    "public conversation",
    "secret redaction",
    "target permission",
    "webhook safety"
  ],
  "tags": [
    "authorization",
    "confirmation",
    "redaction",
    "security"
  ],
  "relatedActions": [],
  "relatedActionPrefixes": [
    "arinova.webhook."
  ],
  "url": "https://docs.arinova.ai/en/kb/webhook/permissions-and-safety/"
}
---

All webhook actions derive identity from `ActionContext::owner_id`; a model-supplied user id cannot widen scope. They also require an explicit per-webhook Agent grant capped by both the Agent owner and webhook owner. `read` permits list, get, fire-event history, and payload lookup; `write` also permits update, cancel, and rotate. Missing, revoked, read-only-for-write, and cross-owner resources all return `resource_not_found`. Target execution separately checks permission to the referenced conversation or board and rechecks the captured target configuration at dispatch time.

Plaintext signing secrets are display-once for create and rotation. They are removed from idempotency replay and covered by result redaction. Payload and filtered header fields are also redacted from persisted action results, are owner-only, expire after 24 hours, and have an audited 30-requests-per-minute access path.

Registry policy remains authoritative. Creating a webhook requires the owner-managed `canCreateWebhook` capability; the new webhook records its creating Agent and grants that Agent write access atomically. The grandfather migration granted existing Webhooks only to active external Agents; platform Agents received zero grants and may see an empty list until the owner shares each Webhook. An Agent may create a webhook-backed Trigger only when it can read that webhook. Rotation and cancellation require user confirmation and strict drift protection. Create, update, rotate, cancel, and payload-detail actions are not allowed in public conversations; read-only list/get/history actions may be available there, subject to the explicit grant.

Inbound delivery itself authenticates with HMAC, timestamp tolerance, and nonce replay protection, and enforces payload-size, rate, enabled, status, and expiry gates. Platform Knowledge can explain these rules but cannot add an action, bypass confirmation, reveal a secret, or grant access to a target resource.