What Is AI TRiSM?

How Does Gartner Define AI TRiSM?

AI TRiSM, short for AI trust, risk and security management, is Gartner's framework for keeping AI systems trustworthy, secure and compliant. Its technical capabilities monitor, validate and enforce across the AI life cycle, and Gartner's recommended actions pair them with enforceable AI policies, an inventory of AI in use, and data and access governance.

Gartner's own definition sits in the FAQ of AI Governance Requires More Than Policies, an article by Gartner analyst Avivah Litan dated June 10, 2026: "AI TRiSM (AI trust, risk and security management) is a framework and set of technical capabilities that ensure AI systems are trustworthy, secure and compliant through continuous monitoring, validation and enforcement."

• Risks in scope - the same article says AI risks "span multiple layers of the AI life cycle", among them "Data risk, including exposure, misuse or improper access" and "Output risk, including inaccurate, biased or harmful outcomes".
• Controls beyond policy - Gartner sets AI TRiSM against policy documents alone: "Rather than relying on static policies, AI TRiSM introduces capabilities for continuous monitoring, validation and runtime enforcement."
• A market of tools - Gartner also tracks the vendors of these capabilities as a market, in a Market Guide whose public summaries supply the layer names below.

The trust in the name refers to how trustworthy the system is. How far people should rely on an AI system's output is a separate question, covered in AI trust.

Why Do AI TRiSM Explainers Disagree on Pillars and Layers?

Explainers disagree because Gartner has described AI TRiSM in more than one way. The table lists the main versions they draw on in date order, with every public source read on October 28 or 29, 2026:

Gartner's public 2026 article names neither the pillars nor the layers, so an explainer that lists either is drawing on other Gartner material: the pillars in use by 2023, or the layers of the 2025 Market Guide, which are described in public only by summaries.

What Are the Layers of AI TRiSM?

Gartner's Market Guide for AI TRiSM, published to Gartner clients on February 18, 2025, sorts TRiSM technology into layers. Public summaries of the guide name four: AI governance; AI runtime inspection and enforcement; information governance; and infrastructure and stack, all resting on traditional technology protection such as identity, network and endpoint security.

The Market Guide itself is not quoted here, and Gartner's public article does not list the layers, so their names come from those summaries. The descriptions and example controls in the table are this article's own:

None of the layers is labeled testing, yet the controls in each one, such as the AI system register or the hold on payouts to new bank accounts, need a test that shows they work.

What Were the Earlier Four Pillars of AI TRiSM?

In her 2023 article, Litan wrote that AI TRiSM "includes solutions, techniques and processes for model interpretability and explainability, privacy, model operations and adversarial attack resistance". Explainers usually list them as four pillars with these labels:

• Explainability and model monitoring - showing how a model reaches its outputs and watching how it behaves once it runs. Production signals such as latency, cost, errors and sampled output quality are covered in AI monitoring.
• ModelOps - managing models through their life cycle, from approval to retirement. The inventory, model cards and re-validation after a model change are covered in AI model governance.
• AI application security - Litan's adversarial attack resistance, meaning defenses against attacks such as data poisoning, prompt injection and goal hijack, which the guide to AI security sorts by layer.
• Model privacy - protecting the personal and confidential data a model was trained on or can reach, so that it neither appears in outputs nor reaches the wrong user.

The arXiv review, by Shaina Raza, Ranjan Sapkota, Manoj Karkee and Christos Emmanouilidis, carries the pillars over to LLM-based multi-agent systems. Its version 5, of December 18, 2025, focuses on "five key TRiSM pillars: Explainability, ModelOps, Application Security, Model Privacy, and Governance", where its first version, of June 4, 2025, had four.

Pillars name capabilities, while layers say where a control sits in the technology. Plan tooling by layer, then check by pillar that every capability has an owner.

How Do You Put AI TRiSM in Place?

Gartner's June 2026 article lists five recommended actions under the heading "What CIOs and AI leaders should do now". Each is quoted below in Gartner's words, followed by what it means for the payments agent:

• Set enforceable policies - "Define enforceable AI policies aligned to risk, regulation and ethics." Enforceable means checkable: a rule that payouts to a newly added bank account, or above the approval limit, wait for a named approver can be tested, and a rule to use AI responsibly cannot.
• Inventory AI - "Establish full visibility by discovering and inventorying AI across the enterprise." The payments agent is listed with an owner, its tools and its largest possible payout.
• Govern data and access - "Strengthen information and access governance to protect AI data and access." This decides which seller records the agent's tools can read, and with which credentials.
• Monitor, validate and enforce - "Implement AI TRiSM capabilities to enable continuous monitoring, validation and enforcement across the AI life cycle." For the agent, this covers testing its payout checks as well as watching them. That life cycle, applied to agents, is the agent development lifecycle, from planning and building through testing and release to operating and monitoring.
• Govern in real time - "Evolve toward ongoing governance processes that operate alongside AI systems in real time." An owner reviews held payouts as they arrive.

Gartner's list places validation across the AI life cycle without fixing a point for it. For an agent that acts, part of it has to come before release:

• Output filters come late - by the time an output filter reads a reply, the tool call behind it may already have run, as the opening payout shows.
• Excessive agency - OWASP files this exposure under LLM06:2025 Excessive Agency, "the vulnerability that enables damaging actions to be performed", rooted in excessive functionality, permissions or autonomy. Its mitigations include human approval of high-impact actions before they are taken, and authorization checks inside the downstream systems themselves, so that an LLM is never the one deciding whether an action is allowed.
• Litan's 2023 article already said: "Don't wait until models are in production to apply AI TRiSM."

Outcomes in NIST AI 100-1, the NIST AI Risk Management Framework, line up with these actions. The editorial pairing below covers actions 2, 4 and 5, and TEVV in it is NIST's shorthand for test, evaluation, verification and validation:

How Is AI TRiSM Different From AI Governance, the NIST AI RMF and ISO/IEC 42001?

Several other names come up beside AI TRiSM in AI risk work. Who publishes each one, and whether anyone is bound by it, tells them apart:

• AI governance - governance decides who owns each AI system, which uses are allowed and what evidence is kept. Gartner's article says AI TRiSM "provides the technical foundation and controls to operationalize modern AI governance"; building the governance side is the subject of an AI governance framework.
• NIST AI RMF - NIST's functions and its TEVV practice are explained in depth in the AI risk management framework guide.
• ISO/IEC 42001 - when a customer asks for a certificate covering how an organization manages AI, this is the standard certification bodies audit against.

What Changes in AI TRiSM When an AI Agent Can Act?

Gartner's 2026 article says agentic AI, which can take actions with limited human intervention, is changing risk profiles and raising the need for adaptive oversight. For a payments agent, the change starts with its tool calls:

• Tool-call inspection - an agent can call the payout tool and then decline in its reply, so a runtime check that reads only the conversation never sees the payment. The guide to AI guardrails shows how to test a tool-call rail by reading both the call log and the system that tool updates.
• Pre-execution checks - a payout can only be stopped before the money moves: by a check that runs after the agent requests the call and before the payments tool executes it, or by authorization inside the payments system itself, as OWASP advises. Those checks are the controls to test hardest before release.
• Evidence from the payments system - a passing test means the payments system shows the payout that policy allowed and no other, read back with read-only credentials rather than taken from the agent's message.
• Tool-call scoring - the arXiv review proposes a Tool Utilization Efficacy score, which "evaluates how correctly and efficiently agents invoke external tools", scored on tool selection, argument validity, execution success, outcome correctness and efficiency. Those five parts make a usable checklist for the payout tool's tests.
• Agentic risk lists - the OWASP Top 10 for Agentic Applications (2026), whose entries are explained in AI agent security, names risks specific to agents, such as goal hijack and tool misuse, that runtime controls have to catch and pre-release tests can try to provoke.

Which AI TRiSM Controls Can You Test Before an Agent Ships?

A test of the agent itself can check a control before the agent holds the permission that control is meant to limit. The table maps each layer to what such a test can check for the payments agent, with category names from the Agent Assurance docs; the mapping is this article's own.

• Must-not-call rules - a scenario can expect the payout tool not to be called, for example before an approver has signed off, and the run compares that expectation with the tool calls the agent's hooks report.
• Read-only verification - calling the payout tool to see whether a payout exists would send one, so verification needs a read endpoint or a read-only tool.
• A test can grade only what some record shows, such as a call log or the payments ledger, so a control that leaves no trace cannot be confirmed. AI verifiability is about building agents whose actions leave a record a test can read.
• For chat, voice and phone agents, AI red teaming attacks what the agent says, with attempts such as prompt injection, jailbreaks and data exfiltration.

Testing an Agent's Policies, Attack Resistance and Data Handling With Agent Assurance

Before the payments agent gets live payout permission, you can test its controls with TestMu AI's Agent Assurance, which tests agents that use tools to change external state. You run it through Rook CLI, its terminal client, with the command rook: it builds scenarios from the agent's code or spec, runs them against the agent itself through a profile (HTTP, a command or an MCP tool) and grades each acceptance criterion against evidence the run produced.

Most evaluation and observability products judge an agent by its answers and logged traces. Agent Assurance looks instead at what a run did to the systems around the agent, such as a staging payments ledger, in these ways:

• Policies in the criteria - your written policies, such as the hold on payouts to newly added bank accounts, become acceptance criteria next to the ones Rook CLI generates.
• Evidence sources - replies are judged on quotes of what the agent actually output, and actions on what the profile's hooks report, such as tool calls and changed state, or on a read-only lookup made through a tool your team provides and approves. A model judge grades part of the criteria, and a payout the agent only claims, with no evidence behind it, stays unverified.
• Unable to Verify - besides Pass and Fail, a criterion can come out as Unable to Verify, which is counted on its own, outside the pass rate, so a control no evidence could settle shows up as a gap rather than a pass.
• Run files - every run leaves plain files in your project: a snapshot of the scenarios it ran, the agent version and profile revision, and each verdict with the quotes behind it. An AI audit can draw on those files as evidence, although Agent Assurance is not itself an auditor.

The category names in the controls table come from the Agent Assurance test scenarios docs, read on October 29, 2026; no scenarios were generated or run for this article. A plain rook generate plans the functional and adversarial classes:

• Default plan - for a small agent, the default plan may contain no attack at all, so request adversarial scenarios by class or by category.
• Attack patterns - adversarial scenarios are built from 25 attack patterns, and some of them are skipped until the profile can supply seeded data, evidence collected outside the agent or a fresh session.
• Security mapping - the adversarial scenarios are tagged with entries from the OWASP Top 10 for LLM Applications (2025) and the OWASP Top 10 for Agentic Applications (2026), and with techniques from MITRE ATLAS, MITRE's public knowledge base of attack techniques against AI systems. Since version 0.1.11, each generated attack also names the guard or control under test in its target_control field.
• Red-team coverage - when a run includes adversarial scenarios, its report adds an OWASP red-team coverage table. A row with no scenario behind it means that entry was not tested, which says nothing about whether the agent resists it. OWASP has since published a 2026 LLM list, compared with 2025 in LLM security.

The command below follows the documented form for requesting categories by name, here four of those in the controls table. Generating spends credits, and Rook CLI shows its plan with the estimated credits before it writes a scenario:

rook generate \
  --category policy_violation,pii_leakage \
  --category prompt_injection,hijacking \
  --total 12

• Staging target - every payout the agent sends during a test is real and cannot be reversed by Rook CLI, so run it against staging, with synthetic sellers and a test-mode payments account.
• Approved write tools - before an interactive run, Rook CLI lists the agent's declared write tools, such as the payout tool, and asks for your approval; in CI, where no one can answer a prompt, grant the exact rules up front. The Rook CLI permissions and safety guide covers those rules.
• Pre-release scope - Agent Assurance does not block anything at runtime, monitor production traffic, scan code or dependencies, or perform penetration testing.

Agent Assurance has no mapping of its own to AI TRiSM, the NIST AI RMF, ISO/IEC 42001 or the EU AI Act: the controls table earlier on this page is an editorial reading, and the product's adversarial scenarios record OWASP and MITRE ATLAS mappings only. It certifies nothing, so your compliance team and auditors decide whether the payments agent meets your payout policy or a regulation.

For agents that talk to people, Agent Testing is the separate product: it holds simulated conversations with chat, voice, phone, video and image agents and scores the replies, before release and after it.

Agent Assurance is self-serve and generally available. Its 14-day free trial includes 4,000 credits, and the Agent Assurance plans page compares what each plan includes. Rook CLI checks for an Agent Assurance plan or an active trial before it calls a model or spends credits.

The first command installs Rook CLI from npm, and the second adds the skill that lets Claude Code run Rook CLI for you:

npm install -g @testmuai/rook@latest
npx @testmuai/rook-skill@latest install \
  --agent claude-code

• Install with npm - needs Node.js 20 or newer; Rook CLI runs on macOS and Linux, and 64-bit Windows through npm or WSL.
• Install without Node - on macOS and Linux, Homebrew or the shell installer needs no Node; the Rook CLI installation guide covers both.
• Coding-agent skill - npx @testmuai/rook-skill, the skill installer, requires Node.js 22 or newer.

Teams that need an Enterprise plan can Book a Demo.

TestMu AI was named a Leader in the 2026 Gartner® Magic Quadrant™ for Agentic Software Quality Assurance Platforms. That report is separate from the Gartner AI TRiSM research this page describes.

Start AI TRiSM With an Inventory and One Pre-Release Test

Start with an inventory: every AI system in use, whether your team built it or bought it, with an owner beside it and a flag on each one whose tools can move money or change records. Pick one flagged system, such as the payments agent, turn three lines of its payout policy into acceptance criteria, and test them against staging before its permissions grow.

For an agent that acts, run those criteria with Rook CLI and read each Unable to Verify result as missing evidence about the control it was meant to check. The Agent Assurance results and evidence guide explains how to read each verdict.

Note: AI assistance was used in researching and drafting this article. Sirajuddin Khan (Vice President of Product Management at TestMu AI, expertise in agentic AI and multi-agent systems) wrote it as author of record, with Maneesh Sharma, Chief Operating Officer at TestMu AI, as reviewer. Before publication, each statistic, link and product claim was checked against primary sources: Gartner's public article on AI TRiSM and a 2023 byline article by a Gartner analyst, the arXiv review of TRiSM for agentic AI, NIST, OWASP and MITRE, plus TestMu AI's product documentation, all used following our editorial process and AI use policy.

Gartner, Magic Quadrant for Agentic Software Quality Assurance Platforms, By Ross Power, Sushant Singhal, C.A. Swan, 12 October 2026.

Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner's business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.