Threat Tribunal: AI and Cloud Security Review Harness
Security Findings Your Team Can Prove and Act On
Threat Tribunal reviews your AI-enabled application and live Azure
environment together. The review finds security risks across application code,
AI services and deployed cloud controls and shows how the risks connect.
Each supported finding is paired with a verifiable fix, and the report
is written around what the review finds in your system, not filled
into a fixed template.
Find security risks
Inspect application code, AI behaviour and deployed Azure services and controls together, then show how the risks connect.
Challenge every conclusion
Separated AI reviewers independently challenge each proposed finding. Only evidence-backed conclusions reach human review.
Deliver actionable work
Approved findings automatically become owned Azure DevOps work items with supporting evidence and clear acceptance criteria.
Threat Tribunal: the same pipeline applies to any engagement. Open
the diagram for a full-size view.
This demonstration runs Anthropic Claude models, Fable, Opus
and Sonnet, in separated proposer, challenger and arbiter roles.
If Fable declines a security prompt, the harness falls back to
Opus. Engagements run on client-approved enterprise AI
service(s).
An engagement delivers two complete reports. Click either to view:
Source evidence
Application and AI Security Review
Code, prompts and model integration
Reads the source, the prompts and the pipeline for the places where
a poisoned document could start giving your system orders.
Checks AI manipulation, safety retesting, access boundaries, safe
file and output handling, and third-party software. It verifies
that application code, not the model, controls access and approves
important actions.
Comparing this source evidence with the live Azure review shows
whether the deployed system matches what was built.
Reads the live cloud footprint for the identity, network and
logging gaps an attacker could walk through.
Checks trust boundaries, least privilege, secrets, data protection,
controlled releases, and operational monitoring. It verifies that
deployed identity, network and logging controls match the intended
architecture.
Comparing the live cloud setup with the Application review shows
whether code and intended controls were deployed correctly.
Prompt Injection: Hidden instructions inside an uploaded PDF that make your AI model obey the attacker instead of you. Every customer document your system feeds to an AI model is untrusted input.
Sensitive Information Disclosure: Personally identifiable information (PII) leaking into model outputs and logs, where people who should never see it can read it.
Improper Output Handling: AI output written into your business records without review, so a wrong answer becomes the official number.
Denial of Wallet: One malicious upload that makes your AI model run over and over, and you pay the bill.
Where cloud risk hides
Excessive Agency: An AI identity with more access than its task needs, handing an attacker your files, databases and secrets.
Public Network Exposure: Services that should be internal are open to the internet and nobody is monitoring them, so attackers can keep trying until something is exposed.
Secrets Sprawl: Passwords, keys and connection strings stored without enough protection, or where they should never be, so one leak unlocks whatever that secret protects.
Silent Logging: Security logs that never turn into alerts, so a break-in goes unnoticed.
Open the diagram for a full-size view.Open the diagram for a full-size view.
Automated delivery
Turning Findings Into Action
Once the reports are validated, approved findings are automatically
synced into Azure DevOps as Features and User Stories. Each item
includes an owner, clear acceptance criteria, dependencies and links
to the supporting proof.
Running the sync again updates the existing work items instead of creating
duplicates.
Azure DevOps Features and User Stories, with a Jira plugin for teams on Atlassian
Includes
Ownership, acceptance criteria, dependencies and supporting proof
Safe to rerun
Existing work items are updated without creating duplicates
How an Engagement Is Governed
A Threat Tribunal engagement is an AI-assisted assessment, not an
autonomous scan. It runs under written client authorization and
these standing controls:
Written approval firstAI-assisted analysis is authorized in writing, and every AI service and tool that may receive client information is named and approved before any evidence is shared.
Enterprise AI services onlyReviews run on client-approved enterprise AI services whose commercial terms exclude client data from model training.
Least-privilege accessDedicated, time-limited, read-only credentials. Any active test requires separate written authorization.
No secrets to the modelSecret values, production records and personal information stay out of model input unless separately approved and minimized.
Evidence before findingsModel output alone is never evidence. Open-source scanners run locally as tools, and their output is a candidate until it is validated. Every material conclusion traces to captured evidence you can reproduce.
Human accountabilityA named human assessor validates every finding and signs off the report. Access is revoked and temporary data deleted at close-out.
Evidence Trail
Threat Tribunal turns a security review into an evidence trail your
team can understand, challenge and act on.
Find security risksTrace how AI, application code and Azure controls can fail across their boundaries.
Prove every conclusionLink each risk to reproducible code, configuration and test evidence.
Verify the responsePair every risk with a concrete fix and a pass condition your team can check.
What an Engagement Delivers
Two security reviews: the live Azure environment and the application source code
A clear record showing the source behind every conclusion
Architecture and trust-boundary diagrams as editable draw.io and PlantUML files your team keeps
A prioritized Azure DevOps backlog with owned Features and User Stories
A plan for turning the agreed security rules into checks on every build
What You Are Reading
Both reports are demonstration deliverables: they show the complete
structure, method and evidence discipline of a Threat Tribunal
engagement, chapter by chapter. All severity examples are fictional,
written to show how risks are communicated, remediated and verified;
severity labels apply only to those fictional examples, and none
describes a real finding. This site contains no client names,
identifiers, resource names, source paths, or any combination of
details that could reconstruct a client environment.
Limitations
Threat Tribunal is a review harness informed by OWASP, NIST and MITRE
guidance. It is not a penetration-test report, a certification or an
assurance opinion. Inclusion of a topic means it was assessed, not
that a finding existed.
About Us
We build agentic AI platforms on Azure and run AI/LLM security and
cost optimization assessments of production GenAI systems. One rule
anchors both: code owns deterministic facts, and LLMs are bound to
reasoning, annotation and judgment.
