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

# Security

> Set up Security in Ravenna: a low-friction reporting path for incidents and phishing, and access reviews that produce evidence instead of a spreadsheet.

A Security desk has an unusual constraint: the requests you most want are the ones people are most reluctant to file. Someone who clicked a link is deciding whether reporting it is worse than staying quiet. Every design decision here should reduce that friction.

## What Security owns in Ravenna

<CardGroup cols={2}>
  <Card title="Incident intake" icon="siren" href="/guides/playbooks/security/incident-intake" horizontal>
    A reporting path so easy that people use it, wired to on-call.
  </Card>

  <Card title="Access reviews" icon="shield-check" href="/guides/playbooks/security/access-reviews" horizontal>
    Who has what, reviewed on a schedule, with the trail to prove it.
  </Card>
</CardGroup>

## Suggested shape

Two surfaces, deliberately different:

* **A public channel** for reporting. `#security` should be somewhere anyone can post without asking permission, because a private workspace adds a step exactly where you cannot afford one.
* **Private tickets** for anything under investigation. This is how you get open reporting without the investigation being visible to the company.

<Warning>
  Every workspace member can see every private ticket in their workspace. Private tickets hide an investigation from the wider company, not from the Security team. If you need a genuinely restricted subset, that is a separate workspace with a smaller membership.
</Warning>

<Callout icon="link" color="#6B7280">Learn more about [private tickets](/documentation/tickets/private-tickets) and [Portal and privacy](/guides/best-practices/portal-and-privacy)</Callout>

## Integrations that change the response

| Integration                                                                                                            | What it unlocks                                                                                 |
| ---------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| [PagerDuty](/integrations/pagerduty/overview) or [incident.io](/integrations/incident-io/overview)                     | Check who is actually on call before escalating, so pages land on a human who is awake          |
| [Jamf](/integrations/jamf/overview), [Fleet](/integrations/fleet/overview), or [Intune](/integrations/intune/overview) | Device compliance state and encryption status on the ticket, plus remote wipe as a gated action |
| [Okta](/integrations/okta/overview) or [Microsoft Entra ID](/integrations/microsoft-entra/overview)                    | Group membership, MFA state, and the entitlement data access reviews run on                     |
| [Vanta](/integrations/vanta/overview)                                                                                  | User accounts synced with authentication methods and MFA status, for audit evidence             |

The on-call integrations matter more than they look. Both check live schedule data every time a workflow runs, so an escalation routes to the person on the rotation rather than to whoever the workflow author knew in March.

## The agent's role, and its hard limit

An agent is genuinely useful here for the documented questions: what counts as a reportable incident, how to report a phishing email, what the password policy is, whether a tool is approved.

It has one absolute limit. It must never assess whether something is a real incident, tell someone a message is safe, or reassure a reporter. A false negative on a phishing question is a breach.

<Prompt description="Answer security policy questions from the knowledge base. Never assess whether a specific message, link, or file is malicious or safe, and never tell a reporter that something is not a problem. For any report of a suspicious message, a lost device, or possible unauthorized access, create a ticket immediately and tell the reporter that Security has been notified.">
  Answer security policy questions from the knowledge base. Never assess whether a specific message, link, or file is malicious or safe, and never tell a reporter that something is not a problem. For any report of a suspicious message, a lost device, or possible unauthorized access, create a ticket immediately and tell the reporter that Security has been notified.
</Prompt>

## Where Security desks stall

<AccordionGroup>
  <Accordion title="A private reporting channel">
    Every barrier between "I think I clicked something" and a filed report costs you reports.
  </Accordion>

  <Accordion title="Ungated remote actions">
    Wipe and recovery key retrieval belong behind approval, always.
  </Accordion>

  <Accordion title="Access reviews as a quarterly spreadsheet">
    If the data is exported, it is stale before the review finishes.
  </Accordion>

  <Accordion title="An agent that offers reassurance">
    This is the failure mode to test for explicitly.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Incident intake" icon="siren" href="/guides/playbooks/security/incident-intake" horizontal>
    Make reporting the path of least resistance.
  </Card>

  <Card title="Access reviews" icon="shield-check" href="/guides/playbooks/security/access-reviews" horizontal>
    Reviews that produce evidence.
  </Card>
</CardGroup>


## Related topics

- [Vault](/documentation/platform/organizations/vault.md)
- [Approval templates](/documentation/tickets/approvals/templates.md)
- [Setup](/integrations/vanta/setup.md)
- [Google Workspace setup](/integrations/google-workspace/setup.md)