> For the complete documentation index, see [llms.txt](https://docs.cortex.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortex.aic.io/workflow-guides/assurance/security.md).

# Security

**Open this area:** In the CORTEX menu, select **Assurance & governance → Security incidents**.

Preserve observed facts, assign an eligible accountable owner, and retain review, mitigation, resolution, or reopening decisions.

**Who uses this:** Analyst, Reviewer, Administrator\
**Open in CORTEX:** `/security/incidents`\
**In-app guide:** `/help?topic=security`

**Expected result:** The incident has protected reporting and a reasoned history of accountable defensive decisions.

## Before you start

* For urgent matters, use the organisation's established urgent reporting channel; the form does not send an automatic external notification.
* Have current security read/report authority and appropriate workspace handling; management requires its separate grant.
* Distinguish observed facts from suspicion and identify the occurrence time and applicable restrictions.

## What to do

{% stepper %}
{% step %}

## Check and report the facts

The incident list shows only records visible to your current account. Edit title and status, then select **Search incidents** to apply them from page 1; the changed-filter message distinguishes typed values from the confirmed results.

**Previous** and **Next** keep the last successful filters and use the service's authorised page, range, and total. A temporary failure leaves the confirmed incidents, handling, and report action available for retry; a current-scope access loss clears them.

If a new report is appropriate, open the incident form. Its prerequisite panel shows reporting authority, required observed facts and handling, and any exact AI origin/eligible-owner requirement.

Enter:

* A 3–200 character title
* Supported kind
* Actual observed UTC time
* 10–6,000 characters of facts

Missing-input messages update as fields change; **Save incident report** is enabled when they are complete. The service rechecks authority and handling before retaining the report.
{% endstep %}

{% step %}

## Report an AI error from its origin

Use **Report an AI error (new tab)** on a generated Product draft, retained origin, or News result. The draft stays open.

Review the captured limitations, describe the observed failure, and retain full handling. Find the eligible Security owner by exact email and save; the first incident revision retains that owner and the exact generation/configuration references.

Reporting requires Security read/report and ordinary AI-origin read access; it does not grant management powers or approve generated content.
{% endstep %}

{% step %}

## Contain an AI failure

A Security manager with AI lifecycle approval authority can inspect the current AI decision and select **Suspend AI and retain mitigation** with failure evidence and a reason.

This stops the complete use case, including a changed configuration. An incident save conflict after the stop does not restore AI: inspect the use case, **Refresh**, and explicitly retry to retain the link.

Entered notes survive ordinary conflicts; access loss clears them. Resolution never reinstates AI. Reassessment, new evidence, and fresh independent AI approval are required before restored use.
{% endstep %}

{% step %}

## Assign accountability

A security manager opens the record, enters the intended owner's **Exact email**, uses **Find eligible owner**, records the assignment reason, and selects **Assign owner**.

The owner must hold current security-management scope for every restriction.
{% endstep %}

{% step %}

## Review before resolving

In **Record a security decision**, select **Under review / reopen**, record assessment and decision reason, then select **Save security decision**.

Original observed facts remain unchanged; later corrections belong in the retained assessment.
{% endstep %}

{% step %}

## Record actual mitigation or resolution

After review, choose **Mitigating** or **Resolved** when justified.

Explain the action, evidence, and remaining risk in **Assessment**, mitigation or resolution evidence, and save the reasoned decision.
{% endstep %}

{% step %}

## Retain and reassess

Inspect **Retained decision history** and **Refresh** for current state.

Reopen a resolved incident through **Under review** with an explicit assessment when new information warrants it; resolution does not remove the report.
{% endstep %}
{% endstepper %}

## Check the result

* Have urgent reporting obligations already been met?
* Are observed facts separate from assessment or allegation?
* Does the record carry all necessary restrictions?
* Is an eligible accountable owner assigned?
* Does resolution explain evidence and remaining risk?

## If you get stuck

<details>

<summary>Why can I report but not assign or resolve?</summary>

Reporting and management are separate permissions, and workspace roles narrow them. An AI reporter selects an eligible initial owner for the exact origin, but later reassignment and management remain separate.

Refer management to an eligible authorised person rather than expecting reporter status to grant those powers.

</details>

<details>

<summary>Why cannot I move a new report directly to Resolved?</summary>

An eligible owner and review must precede mitigation or resolution. Record an **Under review** decision with assessment and reason, then make the justified subsequent decision.

</details>

<details>

<summary>How do I correct the original facts?</summary>

Retain a clear corrective assessment through the management workflow, explaining what changed and why. Original reporting stays immutable so later readers can reconstruct the sequence.

</details>

## Responsibility and limits

* Follow lawful organisational incident procedures and source/person protection. An incident record does not determine guilt, threat status, or permission to investigate.
* Managers record the actual decision-maker and owner appropriately; the software does not conduct surveillance or transmit reports to agencies.

**Reference and scope:** JDP 2-00 (4th ed.), 1.12, 4.18–4.35 and 4.36–4.45 inform protective security and lawful responsibilities. This workflow does not create investigative authority.

## Related workflows

* [Track incident reporting and corrective actions](/workflow-guides/assurance/incident-follow-up.md)
* [Follow an incident through related audit records](/workflow-guides/assurance/incident-correlation.md)
* [Manage accounts, grants and workspace membership](/workflow-guides/assurance/access.md)
* [Preserve an exact revision and manage holds](/workflow-guides/assurance/governance.md)
* [Govern AI use cases and exact data purposes](/workflow-guides/assurance/ai-governance.md)
* [Review a model-assisted first draft from CSV](/workflow-guides/products/ai-assisted-drafts.md)
* [Use Pulse and inspect retained activity](/workflow-guides/assurance/pulse.md)