AI TRiSM for agents: trust, risk and security management
Definition
AI TRiSM, short for AI Trust, Risk and Security Management, is an operating model that treats trust, risk and security as one control system across the AI lifecycle rather than three programmes with separate owners.
For agents, it adds runtime inspection and enforcement to a discipline that previously stopped at model governance.
The framework is usually described in four pillars: governance, runtime inspection and enforcement, information governance, and infrastructure. Agents make the second pillar load-bearing, because the risk now executes.
Why does AI TRiSM matter for agents now?
Agent programmes are failing on risk controls rather than on capability. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls (Gartner). A TRiSM model is one way to make risk controls an engineering deliverable rather than a review gate at the end.
The evidence for runtime risk is no longer theoretical. In the largest public agent red-teaming competition, 1.8 million attacks produced more than 60,000 successful policy violations across 22 frontier agents (arXiv:2507.20526). A discipline built on pre-deployment evaluation alone has no answer to a number produced after deployment.
Model improvement narrows the problem without closing it. On the shared Gray Swan indirect-injection benchmark, the best result at 15 attempts was 0.7% and the best Claude result 1.0%, while several widely used models sat between 24% and 53% (Anthropic Transparency Hub). The spread is the argument for evaluating the whole system rather than the model: the same agent harness can be exposed or reasonably safe depending on which model it calls, which tools it holds and what its policy enforces.
Regulation is converging on the same shape. The EU AI Act requires risk classification, documentation, logging and human oversight for high-risk systems, and NIST AI RMF and ISO/IEC 42001 both expect governance, measurement and monitoring to be evidenced rather than described. TRiSM is a way of organising that evidence once, rather than producing it four times for four frameworks.
How exposed is your setup? Compass gives you a structured read on trust, risk and security gaps across your agent fleet: compass.alyria.ai.
How is AI TRiSM different from AI governance or AI security?
The three are often used interchangeably and they answer different questions. Governance decides what should happen. Security prevents the wrong thing from happening. TRiSM makes sure the two are measured and enforced in the same system.
| AI governance | AI security | AI TRiSM | |
|---|---|---|---|
| Core question | Who decides, and within what limits | How do we stop the wrong action | How do we know the system behaves as agreed |
| Primary output | Policy, roles, risk register | Controls, detections, incident response | A measured control system across four pillars |
| Scope | All AI use, including models | The attack surface and runtime | Governance plus runtime plus data plus infrastructure |
| Owner | Risk, legal, a committee | Security engineering | Shared, with a named owner per pillar |
| Evidence | Decisions and approvals | Decisions and incidents | Continuous measurement and audit trails |
| Failure mode | Documents nobody enforces | Controls nobody governs | Pillars owned separately that never meet |
| Typical cadence | Quarterly | Continuous | Continuous with periodic review |
In practice: Governance without runtime enforcement is a policy library. Security without governance is a set of controls nobody agreed to fund. TRiSM is the join.
What are the four pillars for agents?
Governance
Governance is the inventory, the risk tier and the decision rights. For agents it starts with a register: which agents exist, who owns each one, what it may reach, what risk tier it sits in and which actions require approval. The register has to come from observation as well as from submissions, because a meaningful share of agents are installed rather than requested.
The tiering decides everything downstream. A read-only research agent and an agent that can move money need different controls, different review and different evidence. Treating them the same produces either excessive friction or none.
In practice: Governance is done when you can name the owner of every agent, including the four you found last week.
Runtime inspection and enforcement
This is the pillar agents changed. Evaluation tells you what a model might do. Enforcement decides what the agent may do, per call, with the arguments visible.
Three properties matter. The decision has to happen before the action, not in a report afterwards. It has to work when the model is fully persuaded, which means it cannot depend on recognising the attack. And it has to produce a record that names the agent, the tool, the arguments and the outcome.
In practice: If your control only inspects prompts and responses, you have a filter. Enforcement lives at the tool call and the credential.
Information governance
Agents move data into places that classic data governance never modelled: prompts, context windows, session transcripts, tool responses and vector stores. Each is a copy, and each has an owner.
The pillar answers four questions. Which data classes may an agent read? What may enter its context? How long is a transcript retained? What must be redacted before it leaves the boundary? Answering them in a policy that is evaluated at runtime is what ties information governance to the second pillar.
In practice: A data classification scheme that stops at the database has not been extended to the agent that reads it.
Infrastructure and stack
Agents run somewhere: a laptop, a container, a managed runtime, a vendor's cloud. The infrastructure pillar covers isolation, dependency integrity, secrets handling and the supply chain of tools and servers.
For agents, the supply chain is the part most often missed. Servers arrive from public registries, updates arrive without review, and descriptions change between deployments. Tool poisoning covers the mechanics; the TRiSM point is that it belongs in the infrastructure pillar rather than in a procurement questionnaire.
In practice: Every dependency the agent loads is a grant of authority. Treat it like one.
How to implement AI TRiSM for agents
The order below follows dependency rather than fashion. Each step produces something the next one needs.
1. Name an owner per pillar
Four names, not one committee. Governance, runtime, information and infrastructure each need an accountable person who can say no within their domain. The forum that reviews all four together meets monthly at most.
Tip: Put the endpoint team in the infrastructure seat. Most agent risk is discovered on an endpoint, and a pillar without that access becomes theoretical.
2. Build the register from observation
Combine submitted use cases with endpoint discovery. Record, for each agent, the owner, the tools, the data, the identity and the risk tier.
3. Tier by reversibility and blast radius
Irreversible and externally visible actions at the top. Read-only internal access at the bottom. The tier sets the control set, the approval requirement and the evidence expectation.
Tip: Tier the action, not the agent. One agent often spans three tiers, and policy is easier to defend when the tier is attached to what it does.
4. Enforce at the call
Deploy policy that decides tool calls and network destinations with the arguments in view, and record each decision. Prompt filtering is a complement, not the enforcement point.
5. Govern the data in and out
Define the data classes an agent may read, what may enter context, redaction rules and transcript retention. Express them in the same policy engine so they are enforced rather than documented.
6. Instrument and export
Send signed, chained decision records to your SIEM. A TRiSM programme that cannot answer a question about a specific action in a specific week has no measurable evidence.
7. Measure four things
Denials per thousand calls, refusals in approval queues, agents observed against agents registered, and standing credentials remaining. Each maps to a pillar and each moves in weeks.
Tip: Report the trend, not the level. Stakeholders cannot calibrate an absolute denial count and can calibrate a line that doubles.
8. Rehearse the failure path
Run an incident where an agent is compromised. Confirm who can stop it, how long it takes, and what the record shows. The exercise finds more gaps than any control matrix.
Where AI TRiSM applies in the agent lifecycle
Design
Governance and information governance dominate. Risk tier, data classes and approval requirements are decided here, and the runtime pillar inherits the consequences.
Note: A design review that approves an agent without a tier has not decided anything. The tier is the decision.
Development
Infrastructure and runtime. Dependencies pinned, credentials brokered, policy authored alongside the agent rather than after it.
Pre-deployment testing
All four pillars in miniature: does the agent have an owner, does policy enforce, does data stay in scope, does the dependency set match what was reviewed.
Note: Test the denial paths. Approval and enforcement that have never refused anything are untested controls.
Deployment
Runtime enforcement turns on with the agent, not after it. Confirm the audit path receives events before the first real action.
Runtime
The measured pillar. Decisions, denials and holds are recorded, alerting is live, and the approval queue is monitored for volume and refusal rate.
Continuous monitoring
Review drift across all four pillars: new agents, new tools, new data, new destinations, and the gap between approved and observed.
Note: Drift usually appears in one pillar first and is noticed in another. A new tool shows up in governance and in runtime at the same time, and only the second one pages anyone.
Decommissioning
Retire the identity, remove the tools, delete the data within retention, and close the register entry. A TRiSM programme is only as good as its register, and stale entries erode it quickly.
The takeaway: TRiSM is four questions asked continuously. Who owns this agent, what can it do now, what data does it touch, and what loaded it.
Worked example: an insurer's TRiSM operating model
An insurer has 14 approved AI use cases, three of them agents, and four committees that each believe they own AI risk. Claims triage is the first agent to reach production.
The governance reset. A register is built combining submitted use cases with endpoint discovery, which finds 31 agent installations rather than the three approved ones. Each is assigned an owner and a tier. The three approved agents are tiered by action: claims triage can recommend and cannot decide, the broker assistant can draft and cannot send, the internal research agent is read-only.
The runtime pillar. Policy is deployed at the endpoint and decides tool calls with arguments visible. Claims triage can read a claim, read policy documents and write a recommendation record. It cannot write to the payment system, and any call to an external host is denied by default. The first week records 1,900 decisions and 41 denials, all of which are configuration mistakes rather than attacks, which is the normal starting shape.
The information pillar. The team defines what may enter context: claim details, policy wording, and no member identifiers. Redaction runs before the prompt, and transcripts are retained for 90 days with access controlled. The first week's audit finds one agent including a member identifier in a summary because the field was in the record it read. The field is removed from the tool's response rather than filtered afterwards.
The infrastructure pillar. MCP servers are pinned to specific versions, installed from an internal registry, and their descriptions reviewed as text. The claims agent's server adds a tool in a minor update two months later; the tool-list change is detected against the last observed state and blocked pending review.
The measurement. The monthly review reports four numbers: agents observed against registered (31 against 28, closing), decisions per thousand calls, approval refusals (7%, which the compliance lead calls the first evidence the queue is real), and standing credentials remaining in agent configs (down from 19 to 4).
Month 9, the audit. An internal auditor asks how the insurer knows the claims agent did not send member data externally. The answer is three artefacts from three pillars: the denial policy with its version, the recorded denials for that agent, and the information-flow rule that refuses a send carrying data read in the same session. Producing them takes an afternoon.
The programme worked because the four pillars shared one inventory and one enforcement point. Four committees with four spreadsheets would have produced the same documents and none of the answers.
How standards and regulations influence AI TRiSM
| Framework | Primary focus | Relevance to AI TRiSM |
|---|---|---|
| NIST AI RMF | Govern, Map, Measure, Manage | Supplies the risk lifecycle that the governance pillar implements |
| ISO/IEC 42001 | AI management system with documented controls | Provides the management-system structure and audit expectations |
| ISO/IEC 42005 | AI system impact assessment | Feeds the design-stage tiering and data decisions |
| ISO/IEC 23894 | AI risk management inside enterprise risk | Connects agent risk to the enterprise register |
| EU AI Act | Obligations by risk class, including logging and oversight | Defines the high-risk obligations the pillars have to evidence |
| OWASP Top 10 for Agentic Applications 2026 | ASI01 to ASI10 agent threats | The threat content behind runtime detection and policy |
| OWASP MCP Top 10 (beta) | Tool and server level risks | The infrastructure pillar's supply chain checklist |
| SOC 2 | Security, availability, confidentiality over a period | The evidence standard for access, monitoring and change |
Further reading: AI risk management frameworks for agentic systems for how TRiSM maps to NIST and ISO, Agentic AI governance for the first pillar in depth, and Policy as code for AI agents for how enforcement is authored.
How Alyria handles it
Alyria provides the runtime and information pillars and feeds the other two. Beacon, the signed daemon on every machine, inventories agents, MCP servers, tools and credential sources, which is what turns the governance register from a submission exercise into an observed one.
Lyra is the enforcement pillar: one capability-brokered, information-flow-aware policy decides which tools, servers, models, data and egress each agent may touch, decided locally before the call executes. The information-flow property is what lets a rule refuse a send carrying data the agent read in the same session, without recognising the attack that motivated it.
Umbra handles the secrets side of the infrastructure pillar, and Spectra exports signed, chained OpenTelemetry to Alyria Cloud or your own SIEM, which is the measurement layer TRiSM needs. Observatory gives the fleet view: policy decisions, detections, CVE posture and agent health in one plane.
Free Agent Exposure Report: a read-only starting point that inventories what your agents can reach: alyria.ai/agent-exposure-report.
The platform overview maps the modules to the pillars.
Frequently asked questions
- Is AI TRiSM a product or a framework?
- It is an operating model, popularised by Gartner as a market and architecture category. Products implement parts of it. The framework itself is a way of organising governance, runtime controls, data governance and infrastructure so the same decision is not owned by four teams.
- How is AI TRiSM different from NIST AI RMF?
- They are complements. NIST AI RMF gives a risk-management lifecycle with four functions. TRiSM adds an explicit runtime enforcement pillar and an information-governance pillar, which is where agent risk actually lives. Most mature programmes map the two together rather than choosing.
- Does an agent programme need a separate TRiSM team?
- Usually not. It needs a named owner for each pillar and one forum where the four are reviewed together. A new team with no authority over endpoints or identity tends to produce documents rather than controls.
- What is the first pillar to build?
- Governance, because it decides the rest. In practice that means an inventory with owners, a risk tier per agent, and a written decision about which actions require approval. Without that, runtime controls have no policy to enforce.
- How do you measure trust in an agent system?
- Measure behaviour, not sentiment. Denial rates, approval refusals, incidents per thousand sessions, the share of actions with a recorded decision, and the drift between approved and observed capability set. Trust follows those numbers rather than preceding them.
- Where does information governance fit for agents?
- It decides which data an agent may read, how long it may keep it in context, and what must be redacted before it enters a prompt. Agents move data into prompts and logs, which are new copies that classic data governance never had to account for.
- Can TRiSM be satisfied without endpoint visibility?
- Only partially. A gateway and a model provider's logs describe traffic that chose to route through them. An agent installed locally, a stdio MCP server and a credential in a config file are visible at the endpoint and invisible everywhere else.