Files
riposte-marketplace/integrations/pagerduty/manifest.yaml
T
f3nris 45e9cbd269 feat: declare a risk tier on every command in the catalog
467 of the 1592 commands carried no `risk:`. An unset risk is read as
destructive by the agent approval gate, so half the catalog's write side sat
behind the same prompt — and, in HarfangLab's case, 39 pure lookups did too.
A gate that stops everything stops being read as a signal, which is the
argument already made for the toolkit and for sentinelone (df27876).

The catalog is now 1027 read, 261 safe_write, 304 destructive, with nothing
defaulted. The line follows the one sentinelone drew: impact on the estate,
not reversibility — isolate-agent is reversible and is the canonical
destructive example.

  read        only queries; changes nothing outside Riposte
  safe_write  additive or reversible inside the tool's own case/enrichment
              plane: comments, tickets, tags, alert statuses, threat-intel
              records, sandbox submissions, collection jobs, outbound messages
  destructive changes the estate or weakens a control: containment, blocklists
              and allowlists, exclusions and detection rules, every delete,
              identity and credential operations, code on a host, generic
              API escape hatches

Three calls that were not obvious, and are now applied throughout:

- Undoing a containment is tiered like the containment it lifts. Un-isolating
  a host or un-banning an IP mid-incident is its own decision, not a return to
  a neutral state. The catalog contradicted itself here — crowdstrike's
  lift_containment was destructive while harfanglab's deisolate_from_threat
  was safe_write — so deisolate_from_threat and unquarantine_file are
  re-tiered to destructive, the only two existing tiers this pass changes.
- Retrieving a live secret is destructive: cyberark get_password, delinea
  get_secret, vault read_secret, beyondtrust get_credential. It is a GET, but
  the tier describes the stake, not the HTTP verb.
- Sending outward to humans stays safe_write — slack, teams, twilio, telegram,
  mail. Irreversible, but it is the collaboration plane, not the estate.

An object created but not yet referenced by a rule is safe_write; editing one
a rule already reads is destructive. That is why fortigate create_address and
panos create_custom_url_category are safe_write while update_address_group and
edit_custom_url_category are not.

The template and README never documented the field, which is how 467 commands
came to omit it. Both now carry the tier table and these rules, so the next
integration declares a tier instead of inheriting one.

111 packages get a MINOR bump and a changelog entry: an instance compares
versions to offer an update, so an unbumped manifest would leave the tiers
sitting in the catalog and never reaching the estates that need them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-08 12:55:20 +02:00

131 lines
5.5 KiB
YAML

id: pagerduty
name: PagerDuty
version: 1.1.0
description: "PagerDuty (Events API v2 + REST API v2) — SOC alerting and on-call: trigger/acknowledge/resolve incidents via the routing key, list and read incidents, add notes, and read on-calls, users, and services. Token + routing-key authentication; stdlib-only, no extra Python dependencies."
changelog: "1.1.0 — Declare the risk tier on the 4 commands that carried none: 4 safe_write. An unset risk is read as destructive by the agent approval gate, so the 4 that only annotate sat behind the same prompt as the ones that change the estate. | 1.0.0 — Initial release: trigger/acknowledge/resolve incident, list/get incident, add note, list on-calls/users/services."
category: notification
# Per-instance configuration. api_token authenticates the REST API
# ('Authorization: Token token=<api_token>'); routing_key is the Events API v2
# integration key used to trigger/acknowledge/resolve. from_email is the
# PagerDuty user email required by the REST API for writes such as add-note.
config_schema:
properties:
api_token:
type: string
description: "PagerDuty REST API token"
x-soar-sensitive: true
routing_key:
type: string
description: "Events API v2 integration/routing key (for trigger/ack/resolve)"
x-soar-sensitive: true
from_email:
type: string
description: "A valid PagerDuty user email (required for add-note and other REST writes)"
required:
- api_token
commands:
- id: trigger_incident
name: pagerduty-trigger-incident
description: "Trigger an incident through the Events API v2. Returns a dedup_key used to acknowledge/resolve it."
risk: safe_write
inputs_schema:
properties:
summary: { type: string, description: "Short incident summary" }
source: { type: string, description: "Affected source (host, service, IP)" }
severity: { type: string, description: "critical | error | warning | info (default critical)" }
dedup_key: { type: string, description: "Optional dedup key (auto-generated if omitted)" }
component: { type: string, description: "Optional component" }
required: [summary, source]
outputs_schema: { properties: {} }
- id: acknowledge_incident
name: pagerduty-acknowledge-incident
description: "Acknowledge an incident by its dedup_key (Events API v2)."
risk: safe_write
inputs_schema:
properties:
dedup_key: { type: string, description: "The incident dedup_key" }
required: [dedup_key]
outputs_schema: { properties: {} }
- id: resolve_incident
name: pagerduty-resolve-incident
description: "Resolve an incident by its dedup_key (Events API v2)."
risk: safe_write
inputs_schema:
properties:
dedup_key: { type: string, description: "The incident dedup_key" }
required: [dedup_key]
outputs_schema: { properties: {} }
- id: list_incidents
name: pagerduty-list-incidents
description: "List incidents (filter by status, urgency, and time window)."
risk: read
inputs_schema:
properties:
statuses: { type: string, description: "Comma-separated: triggered,acknowledged,resolved" }
urgencies: { type: string, description: "Comma-separated: high,low" }
since: { type: string, description: "ISO-8601 start time" }
until: { type: string, description: "ISO-8601 end time" }
limit: { type: number, description: "Max incidents (default 25)" }
required: []
outputs_schema: { properties: {} }
- id: get_incident
name: pagerduty-get-incident
description: "Get a single incident by ID."
risk: read
inputs_schema:
properties:
incident_id: { type: string, description: "Incident ID" }
required: [incident_id]
outputs_schema: { properties: {} }
- id: add_note
name: pagerduty-add-note
description: "Add a note to an incident (requires from_email in the configuration)."
risk: safe_write
inputs_schema:
properties:
incident_id: { type: string, description: "Incident ID" }
note: { type: string, description: "Note content" }
required: [incident_id, note]
outputs_schema: { properties: {} }
- id: list_oncalls
name: pagerduty-list-oncalls
description: "List current on-call assignments."
risk: read
inputs_schema:
properties:
schedule_ids: { type: string, description: "Optional comma-separated schedule IDs to filter" }
limit: { type: number, description: "Max entries (default 25)" }
required: []
outputs_schema: { properties: {} }
- id: list_users
name: pagerduty-list-users
description: "List users (optionally filter by a search query)."
risk: read
inputs_schema:
properties:
query: { type: string, description: "Optional name/email search filter" }
limit: { type: number, description: "Max users (default 25)" }
required: []
outputs_schema: { properties: {} }
- id: list_services
name: pagerduty-list-services
description: "List services (optionally filter by a search query)."
risk: read
inputs_schema:
properties:
query: { type: string, description: "Optional name search filter" }
limit: { type: number, description: "Max services (default 25)" }
required: []
outputs_schema: { properties: {} }
- id: test_connection
name: pagerduty-test-connection
description: "Verify connectivity and the REST API token (used by the Test button)."
risk: read
inputs_schema:
properties: {}
required: []
outputs_schema: { properties: {} }