MIT AI Risk Repository for Enterprise AI Governance and Runtime Controls

What the MIT AI Risk Repository provides

The MIT AI Risk Repository is a living catalog of AI failure modes organized by causal and domain taxonomies. For enterprise teams, its value is less about adopting every entry as a standalone checklist item and more about using a stable vocabulary when assessing systems, assigning owners, and deciding where controls must operate.

Causal categories help explain how a failure can arise. Domain categories help locate who should own residual risk and which control families apply. Together they give risk, security, legal, and product stakeholders a shared reference that can be filtered, prioritized, and linked to real assets rather than treated as an abstract catalog.

Why enterprise agents change the control boundary

Model-enabled assistants and agents expand the attack and failure surface beyond prompts and model outputs. Once a system can call tools, write to systems of record, retrieve sensitive data, or chain actions across services, risk is no longer confined to what a release review can inspect in advance.

Many agent and tool-use risks cannot be closed by pre-deployment review alone. Live interaction, privilege escalation through agency, unexpected environment conditions, and data exfiltration paths appear while the system is running. That is why repository-backed assessment should explicitly separate design-time safeguards from runtime enforcement points such as identity, permissions, tool-call policy, monitoring, and audit evidence.

Process to map repository risks to enterprise controls

Treat the repository as an input risk library, not as the finished control matrix. A practical mapping process looks like this:

1. Select repository entries relevant to your use cases, architectures, and data classes.
2. Prioritize risks by likelihood, impact, regulatory exposure, and operational blast radius.
3. Link each prioritized risk to concrete AI assets: models, agents, tools, datasets, and connectors.
4. Assign control owners using domain categories (for example security, privacy, product, legal, or model evaluation).
5. Decide which mitigations belong in pre-deployment governance and which require runtime enforcement.
6. Record residual risk, acceptance decisions, monitoring signals, and evidence expectations in one risk-to-control record.

Pre-deployment governance versus runtime controls

Use the repository’s causal categories to decide where a control must sit. Risks rooted primarily in training data quality, model selection, evaluation coverage, or design assumptions are often best addressed before deployment. Risks that arise from live interaction, tool invocation, privilege escalation through agency, data exfiltration paths, or unexpected environment conditions require enforcement while the system is running.

Domain categories help assign owners. Cybersecurity risks typically connect to security engineering and identity teams. Privacy risks connect to privacy and data governance. Safety and discrimination risks may involve product, legal, compliance, and model evaluation owners. Runtime agent permissions should not remain solely with model developers.

Both layers should reference the same prioritized risk entries so residual risk is visible rather than assumed closed. A practical split keeps design-time decisions authoritative while ensuring runtime policy can still block or escalate high-impact steps that only appear in production paths.

Build a risk-to-control record that audit can use

Audit and assurance teams need a record that connects repository language to operating reality. At minimum, each prioritized risk entry should identify:

• The repository risk reference and a short enterprise-specific description
• Affected assets (agent, model, tool, dataset, connector, environment)
• Business owner and control owners
• Pre-deployment safeguards already applied or required before release
• Runtime controls that enforce, monitor, or contain the risk
• Evidence retained: policy decisions, logs, human overrides, incidents, and periodic review outcomes
• Residual risk status and any accepted exceptions with expiry or review dates

This record becomes the bridge between taxonomy language and day-to-day operations. It also prevents duplicate controls and gaps where multiple teams each assume another function closed the risk.

Evaluation criteria for runtime governance capabilities

When prioritizing runtime investment for agentic systems, evaluate capabilities against the following criteria:

• Policy expressiveness: Can policies express least privilege by agent, tool, action, data scope, and risk tier, including human approval for high-impact steps?
• Enforcement coverage: Are tool calls, API actions, and sensitive data access mediated consistently, or only partially wrapped by application logic?
• Identity binding: Are agent identities distinct, attributable, and bound to scoped credentials rather than broad shared accounts?
• Latency and operability: Is enforcement fast enough for production workflows without encouraging bypass paths around policy checks?
• Log completeness: Do logs capture prompts, tool inputs and outputs, policy decisions, and overrides at a level sufficient for investigation and audit?
• Ecosystem fit: Does the control plane integrate with existing IAM, SIEM, ticketing, and incident response processes already used by the enterprise?

Governance alignment and residual risk

Repository mapping is complete only when residual risk is explicit. Pre-deployment approvals should state which risks remain open, which runtime controls are expected to contain them, and how exceptions are reviewed. Security, privacy, and compliance stakeholders should be able to trace from a repository category to an asset, an owner, a control, and evidence without reconstructing that story from scattered design docs.

For agent and tool-enabled systems, governance maturity depends on whether high-priority repository risks are enforceable at the moment of action, not only discussed at release. Identity, permissions, tool-call policy, monitoring, and audit trails turn a shared risk vocabulary into an operating control system.