Team workflow destinations
Deliver signed, scoped Hyperoru events to Slack, Jira automation, SIEM collectors, policy engines, and generic webhooks.
Workspace Owners and Admins configure team destinations in Settings → Automation. Each destination selects an explicit event allowlist. Hyperoru queues only matching events and retains delivery status, retry history, and the configuration audit trail.
Destination types
| Type | Delivery shape | Typical use |
|---|---|---|
| Slack | Incoming-webhook text and Block Kit fields | Review-ready audit and remediation notifications |
| Jira | Jira automation envelope with a nested Hyperoru event | Ticket rules and ownership routing |
| SIEM | Structured timestamp, event action, organization, and Hyperoru envelope | Security operations correlation |
| Policy | Versioned policy-event envelope | External deterministic decision systems |
| Webhook | Stable Hyperoru event envelope | Customer-built automation |
Integrity and replay
Every request includes delivery, event, timestamp, and HMAC-SHA256 signature headers. The signing secret is generated when the destination is created, encrypted at rest, and shown once. Destinations must use HTTPS and resolve only to public addresses. Redirects are disabled, and production egress controls remain the SSRF backstop.
Delivery failures use bounded exponential retry. Operators can see metadata-only health across the integration fleet; they cannot see signing secrets or customer payloads.
Action boundary
Current integrations deliver events. They do not give an agent ambient permission to create tickets, post arbitrary messages, change policy, or modify a workspace. Ticket creation and other consequential actions require a separate scoped action contract and explicit authorization.
Configuration creation, updates, disables, manual delivery retries, and policy changes create audit events.