# Agent Safety Case: [Agent name] [version]

> Structured argument, supported by evidence, that an AI agent is
> acceptably safe and secure to operate at a stated autonomy level in a
> stated environment. It uses the claims, arguments and evidence pattern
> with element types and IDs in the style of the Goal Structuring
> Notation (GSN) Community Standard Version 3 (SCSC-141C, May 2021):
> goals (claims), strategies (arguments), solutions (evidence), context,
> assumptions, justifications, and challenges that can defeat a claim.
> It records the autonomy level, hazards, the top claim and sub-claims,
> the evidence from evaluations, red teaming and monitoring, open
> defeaters and residual risk, and maps the argument to the OWASP Top 10
> for Agentic Applications 2026 and to the four dimensions of Singapore's
> Model AI Governance Framework for Agentic AI (IMDA). Replace every
> `[bracketed]` value and every row marked *Example*. Worked examples use
> an IT operations agent that reads incident tickets, queries logs and
> runs pre-approved remediation runbooks.

<!--
Guidance: How to use this template
- A safety case is an argument, not a list of controls. Every claim must
  be supported by sub-claims or by evidence, and every piece of evidence
  must say what it shows and what it does not.
- Start with sections 1 to 3 (system, autonomy, hazards). The top claim
  only means something once the operating envelope is fixed.
- Write the defeaters in section 8 honestly. A case with no open
  challenges usually means nobody looked for them.
- Keep the evidence live: link evaluation runs, red team reports and
  monitoring dashboards, and re-check them on the triggers in section 12.
- Related documents: Agentic AI Threat Model (`ai-data/agentic-threat-model`)
  supplies the threats; Human Oversight Design
  (`ai-data/human-oversight-design`) supplies the oversight claims;
  Agent Evaluation Plan (`ai-data/agent-evaluation-plan`) and AI Red Team
  Plan and Report (`ai-data/ai-red-team`) supply evidence; AI Agent
  Specification (`ai-data/ai-agent-spec`) describes the agent.
-->

## Document control

<!-- Guidance: A safety case is valid only for the exact agent build, model, tool set and autonomy level it argues about. Record them all. -->

| Field | Value |
|---|---|
| Document ID | [ASC-2026-001] |
| Version | [0.1] |
| Status | [Draft / In review / Accepted / Accepted with conditions / Withdrawn] |
| Owner | [@safety-case-owner] |
| Approvers / reviewers | [@agent-owner], [@security-lead], [@ai-governance], [@independent-reviewer] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Agent and build | [Name], [version or commit] |
| Model(s) and snapshot | [Provider, model, snapshot date] |
| Tool set version | [Tool catalogue ID and version] |
| Autonomy level argued | [Level from section 2] |
| Notation | GSN Community Standard Version 3 element types (textual form) |
| Next review | YYYY-MM-DD or on any trigger in section 12 |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Agent owner | [@name] | [Accepted / Accepted with conditions / Rejected] | YYYY-MM-DD |
| Security lead | [@name] | [Decision] | YYYY-MM-DD |
| AI governance lead | [@name] | [Decision] | YYYY-MM-DD |
| Independent reviewer | [@name] | [Decision and review report link] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added challenge CH-02 after red team finding RT-014 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Accepted with conditions for autonomy level L2 |

## Contents

<!-- Guidance: Keep this list in step with the headings below. -->

1. [Scope and system description](#1-scope-and-system-description)
2. [Autonomy level and operating envelope](#2-autonomy-level-and-operating-envelope)
3. [Hazards](#3-hazards)
4. [Argument notation](#4-argument-notation)
5. [Top claim and context](#5-top-claim-and-context)
6. [Sub-claims and arguments](#6-sub-claims-and-arguments)
7. [Evidence register](#7-evidence-register)
8. [Defeaters and challenges](#8-defeaters-and-challenges)
9. [Residual risk and confidence](#9-residual-risk-and-confidence)
10. [Mapping to OWASP Top 10 for Agentic Applications](#10-mapping-to-owasp-top-10-for-agentic-applications)
11. [Mapping to the Singapore agentic AI framework](#11-mapping-to-the-singapore-agentic-ai-framework)
12. [Maintenance and review triggers](#12-maintenance-and-review-triggers)
13. [Glossary and references](#13-glossary-and-references)

## 1. Scope and system description

<!-- Guidance: Describe the agent in enough detail that a reviewer can judge whether the evidence covers it. Link the full specification rather than copying it. -->

| Item | Value |
|---|---|
| Purpose | *Example:* Reduce time to mitigate routine production incidents by triaging tickets and running pre-approved runbooks |
| Users and principals | *Example:* On-call engineers; the agent acts with a dedicated service identity |
| Environment | *Example:* Production Kubernetes clusters in two regions; read access to logs and metrics; write access only through the runbook executor |
| Tools | *Example:* `ticket.read`, `logs.query`, `metrics.query`, `runbook.execute` (12 approved runbooks), `ticket.comment` |
| Other agents | *Example:* A log summarisation sub-agent with read-only tools |
| Not in scope | *Example:* Database schema changes, network policy changes, customer communication |
| Specification | AI Agent Specification (`ai-data/ai-agent-spec`) [ID and version] |

```mermaid
flowchart LR
  T[Incident ticket] --> A[Ops agent]
  A --> L[Logs and metrics, read-only]
  A --> S[Summariser sub-agent]
  A -->|proposal| H[On-call engineer]
  H -->|approve| R[Runbook executor]
  A -->|L2 allow-listed runbooks only| R
  R --> K[Production clusters]
```

## 2. Autonomy level and operating envelope

<!-- Guidance: Fix the autonomy level and the envelope (what, where, how much, how fast). The top claim is only about this envelope; anything outside it is out of the case. -->

There is no single normative autonomy scale for agents. Define the scale
you use and keep it consistent with Human Oversight Design
(`ai-data/human-oversight-design`).

| Level | Meaning (*Example* scale) |
|---|---|
| L0 | Suggests only; a human performs every action |
| L1 | Prepares actions; a human approves each one |
| L2 | Acts alone within an allow-list and limits; a human approves anything else |
| L3 | Acts alone across a broad domain; humans monitor and can stop it |
| L4 | Acts alone, sets its own sub-goals, little routine human review |

| Envelope dimension | Bound (*Example*) |
|---|---|
| Autonomy level argued | L2 |
| Actions without approval | Restart a deployment, scale a deployment within 50% to 200% of baseline, clear a named cache |
| Actions needing approval | Every other runbook; any action in a region already degraded by another change |
| Rate | At most 5 autonomous actions per incident and 20 per hour per cluster |
| Data | Logs and metrics; no customer payload data in prompts |
| Hours | Any time; a human on call is always reachable |
| Stop control | Kill switch in the operations console; disables `runbook.execute` within 60 seconds |

## 3. Hazards

<!-- Guidance: A hazard is a state that can lead to harm. List hazards from the agent's actions, from its failure to act, from attacks and from misplaced human trust. Link each to threats in the threat model. -->

| ID | Hazard | Cause examples | Worst credible consequence | Severity | Threat model link |
|---|---|---|---|---|---|
| HZ-01 *(Example)* | Agent runs a runbook that worsens an outage | Misdiagnosis; misleading log lines | Extended outage across a region | High | ATM-T-002 |
| HZ-02 *(Example)* | Agent follows instructions planted in a ticket or log | Indirect prompt injection | Unauthorised action within its permissions | High | ATM-T-001 |
| HZ-03 *(Example)* | Agent loops, repeating actions | Planning error; flapping metric | Resource churn, cascading restarts | Medium | ATM-T-007 |
| HZ-04 *(Example)* | Engineer approves a harmful proposal | Plausible but wrong rationale; alert fatigue | As HZ-01, with human sign-off | High | ATM-T-009 |
| HZ-05 *(Example)* | Sensitive data leaks into ticket comments | Secrets in logs copied to output | Credential exposure | High | ATM-T-004 |
| HZ-06 *(Example)* | Agent identity misused outside the task | Token reuse; over-broad scope | Actions outside the envelope | High | ATM-T-003 |

Severity scale and risk scoring follow the AI Risk Assessment
(`ai-data/ai-risk-assessment`) [ID] so that this case and the risk
register use the same language.

## 4. Argument notation

<!-- Guidance: Explain the notation once so reviewers outside safety engineering can read the case. Keep the textual form even if you also draw diagrams in a GSN tool. -->

The case uses GSN element types in a textual form. GSN Version 3 defines
core elements and two relationships, plus optional extensions; this
template uses the dialectic extension to record challenges.

| Prefix | GSN element | Use in this case |
|---|---|---|
| G | Goal | A claim about the agent that is true or false |
| S | Strategy | The reasoning step that breaks a goal into sub-goals |
| Sn | Solution | A reference to an item of evidence |
| C | Context | Definitions, scope or reference information a claim relies on |
| A | Assumption | A statement taken as true without further support in this case |
| J | Justification | Why a strategy or claim is acceptable |
| CH | Challenge (recorded with the dialectic extension's "challenges" relationship) | A counter-argument or counter-evidence that challenges another element; resolved, open or defeating |

Relationships: "supported by" links a goal to strategies, sub-goals or
solutions; "in context of" links an element to context, assumptions and
justifications. Mark a goal as undeveloped when its support is planned
but not yet written, and never present an undeveloped goal as met.

```mermaid
flowchart TB
  G1[G1 Agent is acceptably safe at L2 in the stated envelope] --> S1[S1 Argue over hazards HZ-01 to HZ-06]
  C1([C1 Operating envelope, section 2]) -.-> G1
  S1 --> G2[G2 Harmful actions are prevented or bounded]
  S1 --> G3[G3 Injected instructions cannot cause actions outside policy]
  S1 --> G4[G4 Humans keep effective control]
  S1 --> G5[G5 Failures are detected and contained quickly]
  S1 --> G6[G6 Sensitive data is not exposed]
  S1 --> G7[G7 Production build matches the evaluated build]
  G2 --> Sn1[(Sn1 Permission tests)]
  G3 --> Sn2[(Sn2 Red team report)]
  G4 --> Sn3[(Sn3 Approval study)]
  G5 --> Sn4[(Sn4 Kill switch drill)]
  G7 --> Sn11[(Sn11 Release attestation)]
  CH1{{CH-01 Approval rubber-stamping}} -.-> G4
```

## 5. Top claim and context

<!-- Guidance: State one top claim that is specific, bounded and testable. "The agent is safe" is not a claim; "safe enough, for this use, at this level, in this place" is. -->

| ID | Element | Statement |
|---|---|---|
| G1 *(Example)* | Goal | The IT operations agent [version] is acceptably safe and secure to operate at autonomy level L2 within the operating envelope in section 2 |
| C1 *(Example)* | Context | Operating envelope, section 2 |
| C2 *(Example)* | Context | Definition of "acceptably safe": no hazard in section 3 has a residual risk above the acceptance threshold in the AI risk assessment [ID] |
| C3 *(Example)* | Context | Hazard list, section 3; threat model ATM-2026-001 |
| A1 *(Example)* | Assumption | The runbook executor enforces its own allow-list independently of the agent |
| A2 *(Example)* | Assumption | An on-call engineer is reachable within 15 minutes at all times |
| J1 *(Example)* | Justification | L2 is chosen because the allow-listed runbooks are reversible within minutes and rate-limited |
| S1 *(Example)* | Strategy | Argue over each hazard: show that it is prevented, bounded, or detected and contained |

## 6. Sub-claims and arguments

<!-- Guidance: Each sub-claim should be narrow enough that evidence can directly support it. If a sub-claim needs a long explanation, split it with another strategy. -->

| ID | Sub-claim | Strategy or argument | Hazards | Evidence | Status |
|---|---|---|---|---|---|
| G2 *(Example)* | Harmful actions are prevented or bounded | Actions are limited by an allow-list, rate limits and blast-radius limits enforced outside the model (S2) | HZ-01, HZ-03, HZ-06 | Sn1, Sn5, Sn6 | Supported |
| G3 *(Example)* | Instructions planted in tickets or logs cannot cause actions outside policy | Untrusted content is labelled as data; tool permissions do not depend on model output; injection attacks were attempted and failed (S3) | HZ-02 | Sn2, Sn7 | Supported with challenge CH-02 |
| G4 *(Example)* | Humans keep effective control over non-allow-listed actions | Approval required in code; approvals show evidence, not only the agent's rationale; approval quality measured (S4) | HZ-04 | Sn3, Sn8 | Challenged (CH-01) |
| G5 *(Example)* | Failures are detected and contained before harm spreads | Monitoring alerts on anomalous action patterns; kill switch tested; loop guard (S5) | HZ-01, HZ-03 | Sn4, Sn9 | Supported |
| G6 *(Example)* | Sensitive data is not exposed through outputs | Secret redaction before prompts and before comments; output scanning (S6) | HZ-05 | Sn10 | Undeveloped (evidence due YYYY-MM-DD) |
| G7 *(Example)* | The model and tools in production are the ones evaluated | Release pipeline pins model snapshot and tool versions; drift check (S7) | All | Sn11 | Supported |

For each strategy, state why its sub-claims together are enough to
support the parent claim (completeness), and record any gap as a
challenge in section 8 rather than leaving it implicit.

## 7. Evidence register

<!-- Guidance: Evidence must be specific, current and traceable. Say what each item shows, its limits, and when it expires. Evaluation scores without the test set and conditions are weak evidence. -->

| ID | Evidence | Type | What it shows | Limits | Date | Link |
|---|---|---|---|---|---|---|
| Sn1 *(Example)* | Permission and allow-list test suite, 64 cases | Test | Executor rejects non-allow-listed runbooks regardless of agent request | Covers current 12 runbooks only | YYYY-MM-DD | [link] |
| Sn2 *(Example)* | Red team report RT-2026-03, 140 injection attempts | Red team | No attempt caused an action outside policy | Attack set fixed at test time; new techniques appear | YYYY-MM-DD | AI Red Team Plan and Report (`ai-data/ai-red-team`) [ID] |
| Sn3 *(Example)* | Approval quality study, 200 proposals with 20 seeded bad ones | Human factors study | Engineers rejected 17 of 20 seeded bad proposals | Small sample; study conditions differ from a 3 a.m. page | YYYY-MM-DD | [link] |
| Sn4 *(Example)* | Kill switch drill | Operational test | Tool disabled in 38 seconds in both regions | Drill in business hours | YYYY-MM-DD | [link] |
| Sn5 *(Example)* | Rate limiter configuration and test | Configuration review and test | Limits of 5 per incident and 20 per hour enforced | Does not cover executor outage | YYYY-MM-DD | [link] |
| Sn6 *(Example)* | Offline evaluation, 300 replayed incidents | Evaluation | Correct runbook chosen in 91% of in-scope cases; no allow-list violations | Replay set from the last two quarters | YYYY-MM-DD | Agent Evaluation Plan (`ai-data/agent-evaluation-plan`) [run ID] |
| Sn7 *(Example)* | Context assembly review | Design review | Tickets and logs wrapped as untrusted data | Review, not a test | YYYY-MM-DD | Context Engineering Specification (`ai-data/context-engineering-spec`) |
| Sn8 *(Example)* | Approval interface design | Design review | Proposal shows the triggering evidence and expected effect | No measured effect yet | YYYY-MM-DD | Human Oversight Design (`ai-data/human-oversight-design`) |
| Sn9 *(Example)* | Production monitoring, 30-day pilot at L1 | Monitoring | No anomalous action pattern alerts unresolved beyond 1 hour | Pilot at a lower level than argued | YYYY-MM-DD | LLM Observability Specification (`ai-data/llm-observability-spec`) |
| Sn10 *(Example)* | Secret redaction tests | Test | Planned | Not yet run | Due YYYY-MM-DD | [link] |
| Sn11 *(Example)* | Release pipeline attestation | Configuration evidence | Model snapshot and tool versions pinned and checked at deploy | Provider-side changes behind a snapshot are outside our control | YYYY-MM-DD | [link] |

*Example:* in Sn3, 17 of 20 seeded bad proposals rejected is an 85%
catch rate, so 3 bad proposals (15%) were approved. With only 20 seeded
cases the Wilson 95% interval for the catch rate is about 64% to 95%, so
the study cannot rule out a much weaker control. That figure feeds
challenge CH-01.

## 8. Defeaters and challenges

<!-- Guidance: A defeater is a reason to doubt a claim, an argument step or a piece of evidence. Record each one, what it attacks, and how it was resolved. An open defeater on a high-severity hazard blocks acceptance unless explicitly accepted. -->

| ID | Challenge | Attacks | Type | Response | Status |
|---|---|---|---|---|---|
| CH-01 *(Example)* | Engineers approved 15% of seeded bad proposals; approval may become rubber-stamping under fatigue | G4, Sn3 | Counter-evidence | Approval now requires choosing the evidence line that supports the action; re-run study with 50 seeded cases at night shift | Open, blocks acceptance of the approval path (G4) |
| CH-02 *(Example)* | Red team attack set may not include multi-step injection via the summariser sub-agent | G3, Sn2 | Gap in evidence | Add sub-agent channel to red team scope; sub-agent has read-only tools so impact is bounded | Open, accepted with condition |
| CH-03 *(Example)* | A1 assumes the executor allow-list is independent; it shares a config repository with the agent | A1 | Assumption challenged | Moved allow-list to a separate repository with separate approvers | Resolved |
| CH-04 *(Example)* | Offline evaluation replay set excludes incidents in regions added this quarter | Sn6 | Evidence limitation | Extended replay set; re-ran evaluation | Resolved |

When a challenge defeats an element, mark it as defeated, show the
impact on the parent claims, and decide whether the top claim still
holds with a narrower envelope (for example L1 only for a region).

## 9. Residual risk and confidence

<!-- Guidance: State what risk remains after the argument, who accepts it, and how confident you are in the case itself. Confidence depends on evidence quality, not on how many items you listed. -->

| Hazard | Residual risk | Main remaining weakness | Accepted by | Conditions |
|---|---|---|---|---|
| HZ-01 *(Example)* | Low | Misdiagnosis on novel failure modes | [@agent-owner] | Allow-list reviewed monthly |
| HZ-03 *(Example)* | Low | Loop guard depends on correct incident grouping | [@agent-owner] | Rate limits in Sn5 stay enforced outside the model |
| HZ-06 *(Example)* | Low | Token scope drift as tools are added | [@security-lead] | Scope review on every tool catalogue change |
| HZ-02 *(Example)* | Medium | New injection techniques (CH-02) | [@security-lead] | Quarterly red team; monitoring alert on tool calls after untrusted content |
| HZ-04 *(Example)* | Medium | Approval quality (CH-01) | Not yet accepted | Close CH-01 before the agent may propose non-allow-listed runbooks |
| HZ-05 *(Example)* | Medium | G6 undeveloped | Not yet accepted | Sn10 before go-live |

Overall decision (*Example*): accept at L2 for allow-listed actions only,
on condition that Sn10 passes before go-live so that G6 is supported;
until CH-01 is closed the agent does not propose non-allow-listed
runbooks, and engineers run them manually. Record the confidence assessment of key argument steps:
where the GSN confidence argument extension is used, attach the
confidence argument at the relevant assurance claim point.

## 10. Mapping to OWASP Top 10 for Agentic Applications

<!-- Guidance: Walk every category so the case shows coverage. "Not applicable" needs a reason. Keep the mapping at claim and evidence level, not only at control level. -->

| OWASP ID | Category | Claims | Evidence | Coverage |
|---|---|---|---|---|
| ASI01 | Agent Goal Hijack | G3 | Sn2, Sn7 | Partial (CH-02) |
| ASI02 | Tool Misuse and Exploitation | G2 | Sn1, Sn5 | Covered |
| ASI03 | Identity and Privilege Abuse | G2, G7 | Sn1, Sn11 | Covered |
| ASI04 | Agentic Supply Chain Vulnerabilities | G7 | Sn11 | Partial: third-party log parser not assessed |
| ASI05 | Unexpected Code Execution (RCE) | G2 | Sn1 | Covered: agent cannot run arbitrary code; runbooks are fixed |
| ASI06 | Memory & Context Poisoning | G3 | Sn7 | Covered: no long-term memory in this build |
| ASI07 | Insecure Inter-Agent Communication | G3 | Sn2 | Partial (CH-02) |
| ASI08 | Cascading Failures | G5 | Sn4, Sn5, Sn9 | Covered |
| ASI09 | Human-Agent Trust Exploitation | G4 | Sn3, Sn8 | Open (CH-01) |
| ASI10 | Rogue Agents | G5, G7 | Sn4, Sn9 | Covered |

Rows above are *Example* content apart from the OWASP IDs and category
names, which follow the published list.

## 11. Mapping to the Singapore agentic AI framework

<!-- Guidance: Use this mapping when you deploy in Singapore or want a governance view next to the security view. The framework is voluntary guidance; check the current edition, because IMDA updated it in May 2026. -->

IMDA's Model AI Governance Framework for Agentic AI groups its
considerations into four dimensions. For a full self-assessment against
the framework, use the Agentic AI Governance Assessment
(`ai-data/agentic-ai-governance-singapore`) and keep this table as the
summary. The names below follow the
January 2026 factsheet and are unchanged in Version 1.5 (published
20 May 2026, updated 5 June 2026); confirm against the current version.

| Dimension | What it asks for (paraphrased) | Claims and evidence in this case | Gaps |
|---|---|---|---|
| Assess and bound the risks upfront | Choose suitable use cases after a risk assessment that weighs autonomy and data access; limit autonomy, tools and data by design | Sections 2 and 3; G2; Sn1, Sn5 | *Example:* None |
| Make humans meaningfully accountable | Allocate responsibility across parties; design oversight that resists automation bias and audit approvals; adapt governance over time | Approvals table; G4; Sn3, Sn8; section 12 | *Example:* CH-01 open |
| Implement technical controls and processes | Controls for planning, tools and protocols in design; pre-deployment safety and security testing; gradual rollout with monitoring | G3, G5, G7; Sn2, Sn4, Sn6, Sn9, Sn11 | *Example:* CH-02 open |
| Enable end-user responsibility | Tell users when and how agents are used; train users to oversee agents while keeping their own skills | *Example:* Engineer onboarding module; agent actions labelled in tickets | *Example:* Training completion not yet evidenced |

## 12. Maintenance and review triggers

<!-- Guidance: A safety case decays as the system and the threat landscape change. Name the events that reopen it and who checks the evidence is still valid. -->

Reopen the case and re-check affected evidence when any of these occur:

- Model or model snapshot change, or a provider notice of behaviour
  change.
- New tool, new runbook on the allow-list, or a raised side-effect class
  (see Agent Tool and Function Catalogue, `ai-data/tool-catalogue`).
- Request to raise the autonomy level or widen the envelope.
- Incident or near miss involving the agent (see LLM and Agent Incident
  Postmortem, `ai-data/llm-incident-postmortem`).
- New OWASP, MITRE ATLAS or regulatory guidance relevant to an open
  challenge.
- Evidence expiry: red team older than [6 months]; approval study older
  than [12 months].

| Review | Frequency | Owner |
|---|---|---|
| Evidence currency check | *Example:* Monthly | [@safety-case-owner] |
| Full case review | *Example:* Every 6 months and on triggers | [@ai-governance] |
| Independent review | *Example:* Before each autonomy increase | [@independent-reviewer] |

## 13. Glossary and references

<!-- Guidance: Define the safety case terms for readers new to assurance work. Cite official sources with the version you checked. -->

| Term | Meaning |
|---|---|
| Safety case | A structured argument, supported by evidence, that a system is acceptably safe for a given use in a given environment |
| Claim (goal) | A statement about the system that the argument sets out to support |
| Argument (strategy) | The reasoning that links a claim to its sub-claims or evidence |
| Evidence (solution) | Artefacts such as test results, reviews and monitoring data that support a claim |
| Defeater (challenge) | A reason to doubt a claim, an argument step or evidence |
| Operating envelope | The bounded conditions under which the claim is made |
| Autonomy level | How far the agent acts without per-action human approval |
| Assurance claim point | A marked point in a GSN argument where a confidence argument is attached |

References:

- Assurance Case Working Group, Goal Structuring Notation Community
  Standard Version 3, SCSC-141C, Safety-Critical Systems Club, May 2021:
  https://scsc.uk/SCSC-141C
- OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications
  for 2026, December 2025:
  https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
- Infocomm Media Development Authority (IMDA), Factsheet: Model AI
  Governance Framework for Agentic AI, January 2026:
  https://www.imda.gov.sg/-/media/imda/files/news-and-events/media-room/media-releases/2026/01/factsheet-model-ai-governance-framework-for-agentic-ai.pdf
- IMDA, Updated Model AI Governance Framework for Agentic AI, press
  release, 20 May 2026:
  https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/updated-model-ai-governance-framework-for-agentic-ai
- Related templates: Agentic AI Threat Model (`ai-data/agentic-threat-model`),
  Human Oversight Design (`ai-data/human-oversight-design`), Frontier AI
  Safety Framework (`ai-data/frontier-safety-framework`), AI Risk
  Assessment (`ai-data/ai-risk-assessment`), Agentic AI Governance
  Assessment (`ai-data/agentic-ai-governance-singapore`).

## Standard and licence note

Structure aligned with the Goal Structuring Notation Community Standard
Version 3 (SCSC-141C, May 2021): element types, relationships and the
dialectic and confidence extensions are referred to by name only, and no
text or diagrams from the standard are reproduced. Based on the OWASP
Top 10 for Agentic Applications for 2026 by the OWASP GenAI Security
Project (https://genai.owasp.org/), licensed under Creative Commons
Attribution-ShareAlike 4.0
(https://creativecommons.org/licenses/by-sa/4.0/): category IDs and short
names are used for mapping, and because the mapping table in section 10
adapts the OWASP category structure, that table is shared under
CC BY-SA 4.0 and any further adaptation of it must carry the same
licence. The four dimensions of IMDA's Model AI Governance Framework for
Agentic AI are named and paraphrased in original words. The autonomy
scale, hazards, claims and examples are original. Check the current
official versions of all three sources before use. Apart from the
adapted OWASP structure, which stays under CC BY-SA 4.0, the original
text is under the template licence. Template licence: MIT.