Governance Lifecycle

Every agent in MITRITY carries a lifecycle status: whether a person has approved it to run and, if not, where it stands. People move it through reviews — an assessment of what the agent is for and what it touches, answered beside what the agent has actually done, and a decision by someone other than the person who asked. One setting for your organization, the lifecycle gate, decides what an agent that is not approved may do at runtime. Every step is recorded on the audit trail.

In short:

1. An agent is registered or discovered. While the gate is Alert or Enforce it starts proposed, with its onboarding review open.
2. For an agent registered through the dashboard or the API, the person who registered it answers the assessment. MITRITY proposes answers from the agent's own record and keeps what it observed beside what was declared.
3. A manager or owner other than the requester (see Separation of duties for the one exception) approves the review, attests to it, sends it back or denies it. The agent becomes approved, changes requested or blocked.
4. The edge reads the agent's status on its next heartbeat. Under Enforce, it refuses every action of an agent that is not approved.
5. The approval schedules the agent's next periodic review. In between, findings about the agent open change reviews when they are severe enough.

Lifecycle statuses

Managers and owners can also set any status directly; see Changing the status directly.

The lifecycle status is separate from the agent's status (for example active or revoked), which the edge and key management set, and from governance_state, the triage state of an agent a SaaS connector discovered. In the dashboard the lifecycle badge reads Approved, Needs review (proposed, under review or changes requested), Blocked or Retired, and the agents list filters by it.

What moves an agent

Resolving a review moves its agent whatever the kind of review and whoever opened it: a change review a finding opened and a periodic review move the agent the same way as an onboarding review. An approved agent keeps its approval while a review of it is open; sending that review back or denying it moves the agent to changes_requested or blocked. Moving an agent to any status other than approved clears its next periodic review date.

Changing the status directly

POST /api/v1/agents/{agent_id}/lifecycle sets the status without a review: for an incident that needs an agent blocked now, or to retire one.

• Managers and owners may use it. Only an owner may set approved this way; a manager approves an agent through a review.
• A reason is required. It is recorded on the agent.lifecycle.changed audit event with the previous and the new status.
• Setting the status the agent already has changes nothing and records nothing.
• A direct approval keeps the agent's next periodic review date; any other status clears it.
• Open reviews of the agent are left as they are.

The lifecycle gate

One setting per organization decides what the lifecycle status means for new agents and at runtime: Off, Alert or Enforce. Alert is the default. The owner changes it on the Governance settings page or with PUT /api/v1/governance/settings, and every change is recorded as governance.settings.updated.

An approved agent is unaffected by every setting.

The edge receives the agent's status and the organization's gate with the agent's mission profile, which it refreshes on every heartbeat. An approval, a block or a change of gate reaches a running edge on its next heartbeat, without a restart. An edge version that does not read the gate is covered too: under Enforce, MITRITY serves it a profile for the agent that denies every action.

The gate refuses actions, not reporting. A refused agent keeps sending heartbeats and events, so the record a reviewer reads keeps growing.

Agents that existed before the gate

• Agents registered before lifecycle governance was introduced became approved when it arrived, so turning it on refused no existing traffic.
• Changing the gate never changes an agent's status. Agents created while the gate was Off stay approved when you move to Alert or Enforce; only agents registered or discovered afterwards start proposed. Moving back to Off leaves every status as it is, and the edge stops acting on it.
• Agents approved this way have no periodic review scheduled: the date is set only when a review approves or attests an agent. To bring one into the review cycle, open a review for it, such as a risk assessment. It keeps its approval while the review is open.

Start at Alert: it shows what is acting without approval and stops nothing. List the agents in each status that is not approved with GET /api/v1/agents?lifecycle_status=<status>, work through their reviews, then move to Enforce.

Governance settings

Every role can read the settings; only the owner changes them. An organization that has never saved them reads these defaults.

Reviews

A review asks one question about one agent and ends with a person's decision. The Governance page in the dashboard is the queue: every review, newest first, with filters for status, type and Overdue only, and the number of pending reviews on the sidebar.

Kinds

Apart from the attestation rule, every kind is handled the same way.

Opening a review

• Members, managers and owners open reviews: from an agent's Governance card with Request review, which offers an onboarding review or a risk assessment when the agent has no open review, or with POST /api/v1/governance/reviews for any kind. The person who opens a review is its requester.
• A review is due review_sla_days after it opens. A review is assigned to the manager role unless the requester assigns it to owner, and a review assigned to the owner role is decided only by an owner.
• A review is open while it is pending or sent back. An agent has at most one open review of each kind opened by people or by the schedule, and one per finding. Asking for another answers 409 Conflict with the open review in the body. A decided or withdrawn review never stands in the way of a new request.
• An agent registered while the gate is Alert or Enforce already has its onboarding review open, requested by the person who registered it, so a request for another onboarding review answers 409 with that review. An agent a connector discovered gets its onboarding review with no requester.
• Opening a review of a proposed agent, or of one whose changes were requested, moves it to under_review. The onboarding review MITRITY opens for a new agent leaves it proposed until answers are submitted.

The assessment

A review that asks for an assessment carries a questionnaire, and its requester answers it. It is the questionnaire your default_template_slug setting names, unless the request names another, and the review keeps it for every revision. A request that names a template that does not exist — neither the shipped one nor one of yours — is refused with 400 Bad Request, as is a template_slug longer than 64 characters. The template that ships with MITRITY, mitrity.default (AI agent risk assessment), asks 24 questions in five sections:

1. Purpose and scope — what the agent is for, how much the business depends on it, its risk tier, and how much it can do without a person in the loop.
2. Data and privacy — personal data, its categories and lawful basis, whether data leaves the organization, and retention.
3. Bias and fairness — whether its outputs affect decisions about people, who could be disadvantaged, bias testing, and how someone affected can challenge an output.
4. Robustness and security — content it did not author, the credentials it uses and how it obtains them, what happens when it is wrong, and monitoring.
5. Human oversight and accountability — the accountable owner, day-to-day oversight, whether a person can stop it immediately, and whether the people it interacts with are told it is an AI agent.

Follow-up questions appear only when an earlier answer calls for them — the lawful basis only when the agent processes personal data, for example. A question that is not asked is neither required nor scored.

The requester answers in the dashboard or with PUT /api/v1/governance/reviews/{review_id}. Each submission replaces the assessment on file, and the dashboard submits only when every required question it shows is answered. Submitting answers for a proposed agent moves it to under_review, and answers that differ from the ones on file raise Governance review requested.

Three answers become part of the agent's record when the review is approved or attested: its use case, its business criticality and its risk tier. An answer outside the vocabulary of those fields is refused when it is submitted.

The advisory score. MITRITY scores every submission from the template's risk weights: the weights of the answers given, summed over the questions the answers make visible, out of the most those questions could score. The band is low below 25% of the maximum, moderate from 25%, high from 50% and severe from 75%. The score is advisory: it is shown to the reviewer and recorded on the review, and it never decides one. A score sent by a client is replaced with MITRITY's own.

An assessment has no score until at least one question it asks is answered. Until then the review records no score and no band: the dashboard and the AI assessment report show it as Not yet assessed, and the API returns it without score, score_max or band — never as low risk. An answer to a question that is not asked does not count. An assessment whose questions carry no risk weights is shown as Not scored. While the requester fills the form in, the dashboard shows the band the answers on screen will be recorded with.

Templates of your own

The owner can adapt the questionnaire. Read a template with GET /api/v1/governance/templates/mitrity.default, change its sections, and write the result under a slug of your own with PUT /api/v1/governance/templates/{slug} and based_on set to mitrity.default. Writing to the same slug again replaces that template and moves its version up. The shipped template cannot be overwritten, and the mitrity. prefix is reserved for the templates that ship with MITRITY.

A template is checked before it is stored: question ids are unique across the whole template, every question is text, boolean or single_select, a condition refers only to an earlier question, a risk weight refers only to an answer the question can produce and never to a text question, a pre-fill names only a field or behavior MITRITY offers, a risk class is one from the risk catalog, and a question that writes onto the agent offers only answers that field accepts — a yes-or-no question writes none, and a choice that sets the criticality or the risk tier offers only their values. A template that breaks a rule is refused with 400 Bad Request naming the problem.

A template of your own works exactly like the shipped one. Its answers are scored from its own risk weights, and the dashboard previews the same score while the form is filled in. The answers its questions mark to be written onto the agent are checked when they are submitted and written onto the agent when the review is approved or attested. The risk classes of its answered questions seed the risk register on approval. To have new assessments ask your template, set default_template_slug to its slug.

Pre-filled from what the agent did

In the dashboard, three questions start from the agent's own fields when a review has no answers yet: its use case, criticality and risk tier. For ten more, MITRITY reads what the agent has done over the last 90 days — its governed actions, DLP matches, prompt-injection detections, credential grants and leases, policy rules, held actions, delegation chains and execution coverage:

Each observed answer states its confidence in one of two words: observed when the window holds records that support it, and no_data when the window holds nothing on the question. There is no word for a guess, and an absence is never turned into an answer: no injection detections does not propose No for content the agent did not author, and no credential grants does not propose No for credentials.

Each observed answer also cites its evidence: the records behind it, each summarized in one sentence that never carries a secret, with a link to where the record lives in the dashboard. Only activity that reached MITRITY is visible, and the summaries say so where it matters.

What is observed is a proposal. MITRITY never writes an observed value into the answers: the requester accepts it with Accept observed, or answers differently. While a review is open the dashboard reads the record afresh; GET /api/v1/governance/prefill returns the same observation over a window of 7 to 365 days, 90 by default.

Observed beside declared

Each time a person opens a review or submits answers, MITRITY observes the agent again and stores the observation with the review, so the record shows what the agent had done at the moment someone vouched for it:

• observed_answers — what the record said about each question, with its evidence.
• answer_sources — for each observed question that was answered: observed when the answer equals what was observed, declared when it differs or the record offered no value.
• declared_answers — the answers whose source is declared, as given.
• observation — the window and the moment of the observation.

These fields are MITRITY's own; anything a client sends under them is discarded. The reviewer sees every answer marked Matches observation or Declared, next to what the record says and its evidence, with one line that counts the answers that match the record, the answers declared differently and the questions with no data.

Decisions

Managers and owners decide pending reviews on the review page, or with POST /api/v1/governance/reviews/{review_id}/resolve:

In the dashboard a note is required to send a review back or to deny it; the API accepts a note with every decision and requires none.

The attestation is a statement in the reviewer's own words: what they checked and what they are signing off. MITRITY trims the whitespace around it and stores the rest exactly as written, up to 4,000 characters; sending one with any other decision is refused. It is on the review, on the governance.review.resolved audit event and in the AI assessment report, and nothing edits it afterwards. Before they sign, the dashboard shows the reviewer the exact text that will be recorded.

When a review is approved or attested, MITRITY also:

• writes the use case, criticality and risk tier answers onto the agent;
• seeds the AI risk register with one entry per risk class the answered questions touch, each recorded as compliance.risk.created;
• records the approval of record: the agent's policy, when it has one, and the version in force at that moment, which drift is measured against;
• schedules the agent's next periodic review.

Only a pending review can be decided. A review that was sent back is waiting for its requester, and deciding it answers 409.

Separation of duties

The person who opened a review cannot decide it: resolving your own review answers 403 Forbidden. The one exception is an organization with exactly one owner, where that owner may decide a review they opened; a pending owner invitation does not count as a second owner. The waiver is recorded on the audit event as separation_of_duties_waived: "single owner tenant". A manager who opened a review cannot decide it, however many owners the organization has.

The requester is also the only person who can change the answers. A reviewer who wants different answers sends the review back, so the record never shows answers its requester did not give.

An API key acts with the role and access scope of the user who created it.

Sending back and resubmitting

Changes requested keeps the review open: the review and its agent both become changes_requested, and under Enforce the agent is refused at the edge until it is approved. The requester revises the answers and submits them again. The review is pending again with its revision number increased, the agent returns to under_review, and Governance review requested is raised again.

A review that nobody requested cannot be sent back. A review opened by a finding, the onboarding review of a discovered agent, a periodic review from the sweep, and a review whose requester's account has since been deleted have no requester on record: nobody can answer them, so they take no answers and are decided on the agent's record as it stands, or withdrawn. A manager or owner who wants an assessment answered withdraws such a review and opens one of their own.

Withdrawing a review

POST /api/v1/governance/reviews/{review_id}/withdraw closes an open review without a decision, with an optional note. The requester may withdraw their own pending review; a manager or owner may withdraw any open review. A review sent back for changes is its requester's to revise, so only a manager or owner withdraws it; that is also how such a review closes once its requester's account is gone. The dashboard offers managers and owners Withdraw review on a review that was sent back.

Withdrawing decides nothing, so it never approves. The agent returns to proposed from the status the review was holding it in — under_review for a pending review, changes_requested for one sent back — and otherwise stays where it is. The audit event records the status the review was withdrawn from; for a review that was sent back it also keeps who sent it back, when, and their note, which the withdrawal replaces on the review itself.

If the review was decided, withdrawn or resubmitted after you read it, the withdrawal answers 409. Read the review again and retry.

Periodic reviews

Approving or attesting a review sets the agent's next review date periodic_review_days ahead, 365 days by default. An hourly sweep opens a periodic_review for every approved agent whose date has passed, and announces it as Periodic review due. It opens one review per date, and none when a periodic review of the agent is already open. The agent keeps its approval while the review is open: a review falling due is not a revocation.

A periodic review from the sweep has no requester and no questionnaire. A manager or owner attests to it on the agent's current record — the review page shows the agent's execution coverage and runtime findings beside it — or denies it, and attesting schedules the next date. To have an assessment answered again, withdraw it and open a periodic review of your own.

Under Off, the sweep opens no periodic reviews and clears the dates that fall due.

Overdue reviews

A pending review is overdue once its due date passes, review_sla_days after it opened. The sweep raises Governance review overdue once for each overdue review, not on every pass. The Governance page shows how many reviews are overdue and lists them with Overdue only; the API lists them with ?overdue=true and counts them as overdue_count in GET /api/v1/governance/reviews/count. Being overdue changes nothing else: the review stays open and the agent stays where it is. A review sent back is waiting for its requester and is not counted as overdue.

Reviews opened by findings

When MITRITY records a finding about an agent that is severe enough, it opens a change review for the agent, titled with the severity, the agent and the finding code, so a detection ends in a decision on the record.

A finding opens a review when its severity is at or above finding_review_severity, which is critical by default. The policy-drift finding is the exception: approving its review is how it is resolved, so it opens one at any threshold. Under Off, findings open no reviews.

There is one review per agent and finding at a time. A finding recomputed on every heartbeat does not open a second review while its review is open, and once the review is closed it opens a new one only for a new occurrence: a finding that cleared and came back after the decision. Posture findings record no start for an occurrence, so once a review of a posture finding is closed, the same finding on the same agent does not open another.

These reviews have no requester and no questionnaire. A manager or owner decides them on the agent's record, or withdraws them. They are announced as Governance review requested, for example: A critical finding is waiting for a change review of support-drafter.

What deciding the review does to the finding depends on its source:

• Host observer — any decision resolves the runtime finding, with the reviewer recorded as the person who resolved it and their note, or a note naming the review, as the resolution.
• Policy drift — approving or attesting records the policy version in force as the approval of record and closes the finding. Denying leaves it open.
• Execution coverage and posture — these findings reflect live state, so the review does not close them. They clear when the condition does, on the next heartbeat or sync.

Whatever the source, the decision also moves the agent, as every review does: approving or attesting makes it approved and denying blocks it. Withdrawing the review leaves the finding as it is.

A detection pattern proposed from an adversarial testing finding also opens a change review, requested by the manager or owner who proposed it and due review_sla_days after it opens, like every review. Approving that review lands the pattern in your DLP library, unbound; the finding itself closes when a later run shows the fix.

Notifications

A connector's newly discovered agent is announced by New SaaS agent discovered rather than by a review request.

• Bell. Every notification is written to the in-app bell. Each user can hide a kind from their own bell under In-app notifications in their profile.
• Slack, email and webhook. These are routed for the whole organization, kind by kind, under Settings → Notifications → Alert routing. Slack delivers only when Slack Integration is enabled with a webhook URL, and email only when Email Notifications is enabled with recipients. The webhook channel posts the notification envelope to every enabled webhook destination — the destinations set up for SIEM forwarding — except syslog destinations.

A notification about a review appears in a scoped user's bell only when the review's agent is granted to them.

The audit trail

Governance changes are recorded as audit events on your organization's tamper-evident audit trail, on the same hash chain as the agents' actions, so an approval sits on one timeline with the actions it allowed. Governance events have source: control_plane, no decision, and the acting person in user_id, which is empty when a finding, the periodic sweep or a connector's discovery opened the review.

The trail also records the status an agent registered by a person started in (agent.created), each risk an approval seeds (compliance.risk.created), and at runtime every refusal by the gate, as an event with blocked_by: lifecycle.

Scoped access

A user whose access scope is scoped works only with the reviews of the agents granted to them:

• The queue, the pending count and the overdue count include only those agents' reviews.
• A review of any other agent answers 404 Not Found, as an unknown review does, whether they read it, answer it, decide it or withdraw it. Opening a review of an agent they cannot see, reading its pre-fill or setting its status answers 404 too.
• Their role still decides what they may do: a scoped manager decides the reviews of their granted agents only.
• A governance notification appears in their bell only when the review's agent is granted to them. In the audit log they see the governance events of their granted agents; changes to the settings and templates name no agent and are not shown to them.

An API key bound to an environment works only with the reviews of that environment's agents, whoever created it. Otherwise an owner is never scoped and sees every review. Settings and templates are the same for everyone.

Reviews and held actions

MITRITY asks people for two kinds of decision:

• A governance review decides whether an agent may run. Its outcome is the agent's lifecycle status, and it is revisited on a schedule or when a finding calls for it.
• A held action decides whether one action may run. A policy rule with hold: true pauses the action until a manager or owner approves or denies it, or its timeout applies; see Approval Workflows.

They meet in three places. Under Enforce, an agent that is not approved is refused before its policy is evaluated, so none of its actions is held; its hold rules apply once it is approved. The assessment's oversight question is pre-filled from the agent's hold rules and the actions it had held. And both kinds of decision are on the same audit trail, each with its own notifications.

From the API

Read and change the settings

curl https://api.mitrity.com/api/v1/governance/settings \
  -H "Authorization: Bearer mk_your-api-key"

{
  "tenant_id": "b2c3d4e5-6f70-4812-9a3b-4c5d6e7f8091",
  "lifecycle_gate": "alert",
  "default_template_slug": "mitrity.default",
  "periodic_review_days": 365,
  "review_sla_days": 5,
  "finding_review_severity": "critical",
  "created_at": "2026-09-01T08:00:00Z",
  "updated_at": "2026-09-01T08:00:00Z"
}

Move to Enforce and have high findings open reviews (owner):

curl -X PUT https://api.mitrity.com/api/v1/governance/settings \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"lifecycle_gate": "enforce", "finding_review_severity": "high"}'

Open, answer and decide reviews

The pending reviews past their due date, and the counts behind the sidebar badge:

curl "https://api.mitrity.com/api/v1/governance/reviews?status=pending&overdue=true" \
  -H "Authorization: Bearer mk_your-api-key"

curl https://api.mitrity.com/api/v1/governance/reviews/count \
  -H "Authorization: Bearer mk_your-api-key"

The list answers {"reviews": [...]}; the count answers {"count": 7, "overdue_count": 2}.

Open a risk assessment of an approved agent and assign it to the owner role:

curl -X POST https://api.mitrity.com/api/v1/governance/reviews \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "subject_type": "agent",
    "subject_id": "3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c",
    "kind": "risk_assessment",
    "assigned_role": "owner"
  }'

The response is the new review. Here it is without its payload, which names the template (your default_template_slug, since the request names none) and carries the first observation of the agent, and no score, since nothing is answered yet:

{
  "id": "4e5f6a7b-8c9d-4e0f-a1b2-c3d4e5f6a7b8",
  "tenant_id": "b2c3d4e5-6f70-4812-9a3b-4c5d6e7f8091",
  "subject_type": "agent",
  "subject_id": "3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c",
  "subject_name": "support-drafter",
  "kind": "risk_assessment",
  "trigger_kind": "manual",
  "trigger_ref": {},
  "title": "Risk assessment: support-drafter",
  "requested_by": "5a6b7c8d-9e0f-4a1b-8c2d-3e4f5a6b7c8d",
  "assigned_role": "owner",
  "due_at": "2026-09-29T09:00:00Z",
  "status": "pending",
  "revision": 1,
  "created_at": "2026-09-24T09:00:00Z",
  "updated_at": "2026-09-24T09:00:00Z"
}

Read what the agent's record says before answering (member and above; template defaults to default_template_slug, window_days to 90):

curl "https://api.mitrity.com/api/v1/governance/prefill?agent_id=3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c&window_days=90" \
  -H "Authorization: Bearer mk_your-api-key"

Two of the ten observed answers:

{
  "agent_id": "3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c",
  "template_slug": "mitrity.default",
  "template_version": 1,
  "window": { "from": "2026-06-26T09:00:00Z", "to": "2026-09-24T09:00:00Z", "days": 90 },
  "observed_at": "2026-09-24T09:00:00Z",
  "observed_answers": {
    "external_destinations": {
      "question_id": "external_destinations",
      "resolver": "external_destinations",
      "value": false,
      "confidence": "observed",
      "summary": "In the last 90 days none of the agent's 1284 governed actions reached a model provider, a destination DLP recorded, or a tool with a hostname. Traffic outside the governed path is not visible here.",
      "evidence": [
        {
          "kind": "metric",
          "ref_table": "audit_events",
          "ref_id": "agent:3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c",
          "summary": "1284 actions evaluated in the last 90 days: 1270 allowed, 9 blocked, 5 held, 0 alerted; average drift 0.12, peak 0.58.",
          "deep_link": "/app/audit?agent_id=3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c"
        }
      ]
    },
    "kill_switch": {
      "question_id": "kill_switch",
      "resolver": "kill_switch",
      "value": null,
      "confidence": "no_data",
      "summary": "The lifecycle gate is alert: blocking this agent here labels it and does not stop it at the edge.",
      "evidence": [
        {
          "kind": "policy",
          "ref_table": "tenant_governance_settings",
          "ref_id": "lifecycle_gate",
          "summary": "The lifecycle gate is alert.",
          "deep_link": "/app/governance/settings"
        }
      ]
    }
  }
}

Submit the assessment (the requester). Send the whole assessment each time: it replaces the one on file.

curl -X PUT https://api.mitrity.com/api/v1/governance/reviews/9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": {
      "template_slug": "mitrity.default",
      "template_version": 1,
      "answers": {
        "use_case": "Drafts replies to customer support tickets for a support agent to review and send",
        "criticality": "high",
        "risk_tier": "high",
        "autonomy": "act_reversible",
        "personal_data": true,
        "data_categories": "Customer names and email addresses in support tickets",
        "lawful_basis": "Performance of the support contract",
        "external_destinations": true,
        "affects_people": false,
        "untrusted_input": true,
        "credential_access": false,
        "failure_mode": "A wrong draft is caught by the support agent who reviews every reply before it is sent",
        "monitoring": true,
        "accountable_owner": "Ana Platform",
        "oversight_mechanism": "approval_required",
        "kill_switch": true
      }
    }
  }'

The response is the review. Its payload keeps the answers exactly as sent and adds MITRITY's score and observation — here without answers and observed_answers:

{
  "id": "9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a",
  "kind": "onboarding",
  "status": "pending",
  "revision": 1,
  "payload": {
    "template_slug": "mitrity.default",
    "template_version": 1,
    "score": 14,
    "score_max": 33,
    "band": "moderate",
    "answer_sources": {
      "autonomy": "declared",
      "credential_access": "declared",
      "data_categories": "declared",
      "external_destinations": "declared",
      "kill_switch": "declared",
      "monitoring": "observed",
      "oversight_mechanism": "observed",
      "personal_data": "observed",
      "untrusted_input": "observed"
    },
    "declared_answers": {
      "autonomy": "act_reversible",
      "credential_access": false,
      "data_categories": "Customer names and email addresses in support tickets",
      "external_destinations": true,
      "kill_switch": true
    },
    "observation": {
      "window": { "from": "2026-06-26T09:00:00Z", "to": "2026-09-24T09:00:00Z", "days": 90 },
      "observed_at": "2026-09-24T09:00:00Z"
    }
  }
}

Here the requester declared that the agent sends data outside the organization although its record shows none, and the record had nothing on credentials or on stopping the agent at the edge; the reviewer sees each of those answers marked Declared.

Attest to the review (a manager or owner who did not open it):

curl -X POST https://api.mitrity.com/api/v1/governance/reviews/9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a/resolve \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "disposition": "attested",
    "attestation_text": "I reviewed support-drafter: what it is for, the data it handles and how a person oversees it. I accept it for production."
  }'

Or send it back with a note for the requester:

curl -X POST https://api.mitrity.com/api/v1/governance/reviews/9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a/resolve \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "disposition": "changes_requested",
    "reviewer_note": "The record shows no data leaving the organization. Name the destinations, or change the answer."
  }'

Withdraw an open review:

curl -X POST https://api.mitrity.com/api/v1/governance/reviews/9d8c7b6a-5f4e-4d3c-2b1a-0f9e8d7c6b5a/withdraw \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"reviewer_note": "Replaced by an incident review."}'

Find and set lifecycle statuses

The agents waiting for a decision:

curl "https://api.mitrity.com/api/v1/agents?lifecycle_status=under_review" \
  -H "Authorization: Bearer mk_your-api-key"

Block an agent now (manager or owner). The response is the agent with its new lifecycle_status:

curl -X POST https://api.mitrity.com/api/v1/agents/3f6c1a2b-8d4e-4f7a-9b0c-1d2e3f4a5b6c/lifecycle \
  -H "Authorization: Bearer mk_your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "lifecycle_status": "blocked",
    "reason": "Credential exposure under investigation; blocked until the incident review closes."
  }'

Query the governance trail

The review decisions on record, and the actions the gate refused:

curl "https://api.mitrity.com/api/v1/audit?source=control_plane&event_type=governance.review.resolved" \
  -H "Authorization: Bearer mk_your-api-key"

curl "https://api.mitrity.com/api/v1/audit?decision=blocked&blocked_by=lifecycle" \
  -H "Authorization: Bearer mk_your-api-key"

Best practices

• Start at Alert. It shows what is acting without approval and stops nothing. Move to Enforce once those agents are reviewed.
• Let the record answer first. Accept the observed answers the record supports. Where you answer differently, say why under Anything else the reviewer should know?
• Attest in your own words. The statement is reproduced in reports for readers who were not there. Say what you checked.
• Choose the finding threshold deliberately. With the default, only critical findings open reviews. Lower it to have high findings open change reviews too.

Related documentation

• Approval Workflows — holds on individual actions, and how they relate to reviews (above)
• Policy Versions — the approval of record a review writes, and the drift finding that opens a change review
• AI Policy Statements — your organization's own commitments, attested by the people who read them; separate from the attestation a reviewer gives on one agent's review
• AI Risk Register — the entries an approved assessment seeds
• Compliance Reports — the ai_assessment report states the latest assessment and every decided review, with each attestation exactly as written
• Compliance Frameworks — how the agent registry, the reviews and the gate count as evidence
• Governance Coverage — what the gate does at the edge
• Tamper-Evident Audit Trail — the chain governance events are written to
• Roles & Access Control — roles, access scope and agent grants