The TriOngle Method
How every TriOngle engagement runs, from scope to retest, and how every finding is recorded. Public, dated and versioned, so you can hold us to it.
Version 1.0Published 4 November 2026Current
Principles
- The system, not the model. We assess the application around the model: its data, prompts, retrieval, tools, agents, identities and the people and systems that consume its output.
- Every finding is proved or reasoned. A finding from testing has a proof of concept you can rerun. A finding from design review states the reasoning and the evidence it rests on.
- Every finding is mapped. Each one carries its place in the frameworks below and the law it touches, so security, engineering and governance work from one record.
- Vendor-neutral. We recommend controls and products on evidence. Tooling we build for the method is published openly.
- Evidence stays in the EU. Test evidence is kept on EU servers only. See data handling.
- Aligned with, never certified by. The method uses the frameworks below. No framework body has certified TriOngle or this method.
Six stages
The same stages on every scope. Which tests run in stage 3 depends on the scope.
Scope
We agree in writing the system and its boundary, the scope code or codes, the frameworks and versions in scope, the questions that matter to you, the rules of engagement for any testing, the people involved, and where evidence will be kept.
Output: a scope statement both sides sign.
Model
We map data flows, trust boundaries, assets and actors, including every model, agent, tool, MCP server and identity. On design scopes this is the core of the work; on testing scopes it decides what to test first.
Output: a trust-boundary diagram and, where the scope includes it, a threat model.
Test
Design review, configuration review and attack testing, as the scope sets. Every test case is tagged with its MITRE ATLAS technique and the OWASP entry it exercises. Attack testing runs only within the agreed rules of engagement, against systems you have authority to let us test.
Output: test records and proofs of concept, kept on EU servers only.
Map
Every finding is written up in the finding record below and mapped to the frameworks and the law it touches. Severity is rated with its reasoning written out.
Output: the finding records.
Report
One plain-language report: a summary written for the board, the technical findings, the governance view (AI Act, ISO/IEC 42001, GDPR) where the scope includes it, and a fix plan in priority order. The report states the method version and the version of every framework it maps to.
Output: the report, and a walkthrough with your team.
Retest and hand over
On testing scopes we retest the fixed findings and issue a retest letter. Test cases are handed over as a regression suite that runs in your CI, so a fixed finding stays fixed.
Output: the retest letter and the regression suite, where the scope includes them.
The per-finding mapping
Every finding is recorded in the same fields. The seven framework fields are filled for every finding where the framework applies; where one does not apply, the record says so rather than leaving it blank.
| Field | Framework and version | What it records |
|---|---|---|
| OWASP LLM | OWASP Top 10 for LLM Applications, 2025 edition[1] | The LLM risk, LLM01 to LLM10 |
| OWASP agentic | OWASP Top 10 for Agentic Applications, 2026 edition, 9 December 2025[2] | The agentic risk, ASI01 to ASI10, where agents are involved[3] |
| MITRE ATLAS | MITRE ATLAS, data version recorded per report (2026.05 today)[4] | The adversary technique ID |
| NIST AI 600-1 | NIST AI 600-1, Generative AI Profile, 26 July 2024[5] | The generative AI risk the finding increases |
| ISO/IEC 42001 | ISO/IEC 42001:2023, Annex A[6] | The Annex A control objective, A.2 to A.10[7] |
| ISO/IEC 27090 | ISO/IEC 27090:2026[8] | The AI security threat and the asset and life-cycle stage it affects |
| EU AI Act | Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744[9][10] | The article the finding touches, and whether it applies to your role and risk class |
| Also, where relevant | GDPR; Cyber Resilience Act; MCP security best practices; CoSAI guidance | The article or section concerned |
The other fields
- ID and title
- A stable identifier and a title that says what goes wrong, not what the test was.
- Side
- Architect, Assure or Govern: which side of the triangle the fix belongs to.
- Severity
- Critical, high, medium, low or informational, with the reasoning written out: impact, likelihood and the preconditions an attacker needs.
- Evidence
- The proof of concept, configuration excerpt or design reference, stored on EU servers only.
- Fix
- What to change, in priority order, and how to verify it.
- Status
- Open, fixed, retested, or accepted by you with a reason.
Illustrative example: a type of finding, not a finding from any engagement
Instructions in a retrieved document make the support agent send email
- Side
- Architect (the fix is a design change); found under Assure
- Severity
- High: an outsider who can get a document indexed can make the agent act; no credentials needed
- OWASP LLM (2025)
- LLM01 Prompt Injection; LLM06 Excessive Agency[1]
- OWASP agentic (2026)
- ASI01 Agent Goal Hijack; ASI02 Tool Misuse and Exploitation[3]
- MITRE ATLAS
- AML.T0051.001, LLM Prompt Injection: Indirect[11]
- NIST AI 600-1
- Information Security, one of the profile’s twelve risks[12]
- ISO/IEC 42001 Annex A
- A.6, AI system life cycle[7]
- ISO/IEC 27090:2026
- Prompt injection, one of the threats the standard covers[8]
- EU AI Act
- Article 15, accuracy, robustness and cybersecurity, if the system is high-risk[13]
- Fix
- Apply the Agents Rule of Two: the workflow that reads untrusted documents may not also send email without a human approval;[14] see AG4 Injection-resistant architecture review
Versions and changes
The method has a version number and a date. A change to the stages or to the fields of the finding record makes a new major version; a change to the frameworks or versions we map to makes a new minor version. Every change is listed here with its date, and earlier versions stay readable.
Every report names the method version it was produced under and the version of every framework it maps to, so a reader in two years can see exactly what it was measured against.
| Version | Date | Change |
|---|---|---|
| 1.0 | 4 November 2026 | First publication. |
References
Numbered in the order they are first cited on this page; each entry links back to the places that cite it. Every source was opened on 4 November 2026.
- ↑ a b 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps. OWASP Gen AI Security Project.
- ↑ OWASP Top 10 for Agentic Applications for 2026. OWASP Gen AI Security Project, 9 December 2025.
- ↑ a b OWASP top 10 for agentic applications 2026: Understanding the risks of agents and tools. Giskard, 18 December 2025. Lists the ten entries ASI01 to ASI10.
- ↑ mitre-atlas/atlas-data. MITRE ATLAS on GitHub. Data version 2026.05.
- ↑ Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). NIST, 26 July 2024.
- ↑ ISO/IEC 42001:2023. Standards Council of Canada, 17 December 2023.
- ↑ a b ISO 42001 Annex A Controls List: All 38 Controls Explained. RiskProfs, 21 July 2026.
- ↑ a b New guidance to help organizations protect AI from security threats. BSI, 27 October 2026.
- ↑ Regulation (EU) 2024/1689 (Artificial Intelligence Act). EUR-Lex, 13 June 2024.
- ↑ Regulation (EU) 2026/1744 of 8 July 2026 (Digital Omnibus on AI). EUR-Lex, 8 July 2026.
- ↑ Indirect, AML.T0051.001. MITRE D3FEND.
- ↑ NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (PDF). NIST, July 2024. Section 2 lists the twelve risks.
- ↑ Article 15: Accuracy, Robustness and Cybersecurity. EU AI Act Explorer.
- ↑ Agents Rule of Two: A Practical Approach to AI Agent Security. Meta AI, 31 October 2025.