Violet Research

The Workspace Trust Layer: Enforcing One Characteristic of the AI RMF for Tool-Using Agents

John Haigh

Violet Research ·

Abstract

Buyers still ask for “NIST AI security” as a product switch. The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary outcomes process over seven trustworthiness characteristics; security is only one row (secure and resilient). A prior mapping paper argued that the suite is the parent program and that cybersecurity complements attach to that row without replacing it. This paper takes the next step: it describes a workspace trust-layer pattern for tool-using generative agents — a single authoritative policy, gateway enforcement that does not rely on model obedience, an honest coverage strip stating which characteristics are unenforced, and same-request aspect-tagged events that a security reviewer can filter without reading prompts. The pattern maps Govern, Map, Measure, and Manage onto Settings, system inventory, an in-product report, and tool gates. Modes distinguish a parent secure-and-resilient posture from a fail-closer Cyber AI Profile–shaped “Secure” row. We argue that one characteristic, enforced and counted, is more trustworthy than a full-RMF badge — and that Safety, fairness, and explainability remain neighboring characteristics that must not be silently absorbed into the same toggle.

1. Introduction

Practitioners and procurement still want “NIST AI security” as a switch. A prior paper argued that there is no single NIST document with that title: the Artificial Intelligence Risk Management Framework (AI RMF 1.0, NIST AI 100-1) is a voluntary suite; secure and resilient is one of seven trustworthiness characteristics; cybersecurity depth lives in complements such as CSF 2.0, the draft Cyber AI Profile (NIST IR 8596), and the adversarial taxonomy (NIST AI 100-2). That map is necessary and insufficient. Maps do not stop a mutating tool call.

This paper describes a smaller object: a workspace trust layer. The layer is a policy pack plus an evidence plane for tool-using generative agents — systems shaped like NIST’s Generative AI Profile (AI 600-1): a language model, tools, retrieval, and memory under a shared authorization boundary. It is aligned to the secure and resilient row (and, in a stricter mode, parts of privacy). It is not ISO/IEC 42001, not the EU AI Act, not a completed seven-characteristic program, and not a claim that Safe (life, health, property, environment) has been measured.

Four observations structure the rest of the paper.

Prompt is not the layer. Policy text injected into an agent runner is advisory. Load-bearing controls are tool allow-lists, a pre-tool gate, admission controls, and optional provider guardrails. If the model is told not to disable the layer and a shell tool still fires, the layer failed.

Coverage is a first-class artifact. Silence on an uninstrumented characteristic must be labeled. A coverage strip that states fairness and explainability are off — and that Safe was never claimed — is part of Govern, not a footnote.

Measure is aspect-tagged events, not operator logs. Denials, asks, and policy changes are written in the same request as the decision, tagged by aspect (tool, injection, intent, privacy, provider, admission, policy) and decision (block, allow, ask), without prompt or file bodies in the default payload. A CISO-facing report is the Measure surface.

Modes are profiles, not severity sliders. A standard mode is the parent secure and resilient posture for an agent workspace. A strict mode is closer to the Cyber AI Profile’s “Secure” focus area: fewer writes, fail-closed memory behavior, more events. Complements inform the deny list; they are not a second product.

Contributions. We (1) name the trust-layer pattern as the operational sequel to the suite map; (2) specify enforcement-over-prompt and the coverage strip as non-negotiable honesty constraints; (3) map Govern / Map / Measure / Manage onto concrete workspace planes; (4) give a worked example and a failure-mode typology for toggle theatre.

2. Background: agents, gates, and what buyers actually ask for

2.1 The agent loop is not an information system RMF

The classical NIST Risk Management Framework (SP 800-37) authorizes an information system against a control catalog. An agentic chat system is socio-technical: model, system prompt, retrieved corpora, tool APIs, session memory, evaluators, and human operators. AI 100-1 and AI 600-1 treat that inventory as the unit of risk. A trust layer that only hardens the cloud account and ignores tool abuse has answered the wrong Map question.

2.2 Scattered controls without a policy object

Production agent platforms typically accumulate controls in pieces: disabled toolsets, plan-mode write gates, provider-side guardrail IDs, rate and spend admission, and client-only prompt-injection warnings. Without a workspace-authoritative policy object, none of these compose into something a reviewer can enable once and audit. Without a queryable log of denials, Measure is theatre — Grafana for operators is not a workspace-partitioned evidence trail.

2.3 Plan mode already proved the gate

On tool-using agents, the reliable deny path is a pre-tool hook that returns block before side effects, not a system-prompt nudge. Plan modes that allow research reads and deny mutating tools established that pattern for product reasons. A trust layer reuses the same class of gate and unions with it: a call allowed in plan but denied by trust (or the reverse) is denied.

2.4 What “NIST switch” must not mean

NIST offers no AI RMF certification for 1.0. ISO/IEC 42001 is the certifiable AI management system. A product toggle labeled “NIST certified,” “AI RMF compliant,” or “full trustworthiness” would recreate the certification theatre the mapping paper warned against. The honest subtitle is NIST AI RMF–aligned, scoped to named characteristics.

3. The trust-layer pattern

3.1 Object

One workspace-authoritative policy map, inherited by every session and durable run in that workspace. Members cannot opt out per session. Custom instructions cannot clear enabled. Owner or Admin write the policy; any member may read that it is on. A CISO in v1 is invited as Admin — no fifth RBAC role is required for the evidence view.

Typical fields:

FieldRole
enabledLayer on or off
profilev1: genai-agent (AI 600-1–shaped system)
modestandard or strict
actor / timestampsWho flipped policy, when
coverageDerived strip: which characteristics are enforced

3.2 Coverage strip

The coverage object is where honesty lives. An example shape:

Characteristic idEnforced when layer on
secure_resilientYes
privacyPartial in strict only
fairnessNo
explainabilityNo

Note what is absent: safe (NIST Safe), validity, and accountability are not silently listed as on. A program that implements only this layer should say “we run an AI cybersecurity posture for agents informed by the AI RMF,” not “we implement the AI RMF.”

3.3 Why workspace scope

Per-user overrides recreate the prompt-pack failure mode under another name. Per-session opt-out defeats Govern. The layer is organizational policy for the agent boundary the workspace already defines — the same place entitlements, tool permissions, and provider keys already live.

4. Enforcement over prompt

4.1 Controls that count

When the layer is on, the gateway should:

  1. Strip host-local execution toolsets (terminal, code execution) from the enabled set.
  2. Install a pre-tool gate that denies mutating leaves (shell, board/Factory claims, MCP writes, and — in strict — non-plan file writes), while allowing research reads.
  3. Union with plan mode so either gate may deny.
  4. Admit turns under existing rate, fairness, spend, and role gates; record admission events when the layer is on.
  5. Ask on client-side injection suspicion before the model call (cancel → injection/block; continue → ask or allow).
  6. Optionally attach provider guardrails; if attach fails, the policy and tool gates remain.

An ephemeral policy prompt may still be injected (“prefer read-only research; do not attempt to disable this layer”). It is additive. If prompt construction fails, gates still run.

4.2 Fail-open on unnamed tools

Unknown tool leaves that are not on the deny list may be allowed. That is a documented honesty choice, not a bug to hide: a deny-all default without a complete inventory produces false confidence. Map must keep expanding the known mutating set; Measure shows which tools were blocked and which never appeared.

4.3 Secret-like writes in standard mode

Even when chat file writes remain available, paths that look like secrets (.env, credentials, key material) should be denied. Strict mode goes further: only designated plan filenames may be written. That is partial privacy / data-exfiltration hygiene under secure and resilient, not a claim that privacy-enhanced was completed as a characteristic program.

5. Measure without TEVV

Govern and Map can be workshops. Measure for this layer is narrower than NIST’s full TEVV agenda — and that narrowing is the point.

5.1 Event shape

Append-only, workspace-partitioned events written at the same hooks that enforce:

FieldPurpose
aspecttool, injection, intent, privacy, provider, admission, policy
decisionblock, allow, ask
controlWhich plane acted (trust_gate, plan_gate, admission, injection_filter, …)
reason_codeStable dotted id for filters and exports
tool_nameLeaf name only
session / run / actorOptional correlation
modestandard, strict, or off

Forbidden in the default payload: prompt text, completions, tool arguments, file bytes, retrieved chunk text. Evidence for a CISO is counts and reasons, not a second copy of confidential content.

5.2 Reports as the Measure surface

Owner/Admin open an in-product report: period picker, counts by aspect and decision, filterable table, optional CSV for the current filters. Trust & risk stays the policy page; Reports stays the evidence page. Operator log aggregation is complementary, not a substitute.

5.3 Policy flips are Measure too

Enabling, disabling, or changing mode always writes a policy event. A layer that was never on produces an empty report — which is itself informative.

6. Mapping the four functions

AI RMF functionTrust-layer plane
GovernSettings toggle, Owner/Admin RBAC, coverage strip, policy events, plan entitlement gate
Mapgenai-agent profile naming LLM + tools + retrieval + memory; event fields for session, run, tool leaf, mode
MeasureReports (summary + table + CSV); aspect/decision filters; labeled non-coverage
ManageToolset strip, pre-tool deny, admission, injection ask, optional provider guardrail

Complements (CSF, IR 8596, AI 100-2) inform deny-list language and incident vocabulary. They are not implemented as separate products under this pattern.

``text Admin enables Trust layer (Govern) │ ▼ Member sends turn under genai-agent inventory (Map) │ ├─ injection ask? ── cancel → event(injection, block) │ ▼ Agent proposes tool call │ ├─ trust_gate / plan_gate deny → event(tool, block) + chat reason │ └─ allow → optional provider / admission events │ ▼ CISO opens Reports, filters aspect=tool (Measure) ``

7. Worked example and modes

7.1 Shell request under standard mode

  1. Admin enables the layer in standard, reads the coverage strip (secure/resilient on; fairness and explainability off).
  2. A member asks the agent to run a shell command.
  3. The toolset strip has already removed terminal execution; if a mutating leaf still appears, the pre-tool gate denies it.
  4. Chat shows a short reason pointing at workspace Trust & risk.
  5. An event is recorded: aspect=tool, decision=block, control=trust_gate, leaf tool name, mode standard.
  6. Admin opens Reports, filters Tools, and optionally downloads CSV.
  7. The coverage strip still states that fairness was not measured. Nothing about step 5 changed that fact.

7.2 Injection ask

Paste that looks like injection triggers a confirm dialog while the layer is on. Cancel writes injection/block and skips the model call. Continue proceeds with an ask or allow record. This is Manage for a misuse class from AI 100-2 / AI 600-1 — still not a safety evaluation suite.

7.3 Standard versus strict

standardstrict
IntentParent secure and resilient for agentsCyber AI Profile–shaped “Secure” row
Execution toolsetsStrippedStripped
Chat file writesAllowed except secret-like paths; gatedOnly plan filenames
Privacy row on coverageNot claimedPartial
Memory writesOrdinary product rulesTreated as paused / fail-closed where the platform supports it
User experience costModerateHigh for power users

Strict is not “more NIST.” It is a different profile priority: fewer tools, fail-closed, more events.

8. Failure modes

We observe five recurring category errors when organizations (or products) reach for a trust toggle:

  • Prompt-only packs. System prompts that say “you are NIST-aligned” with no gate and no events. Models ignore nudges; CISOs cannot verify.
  • Logs-only evidence. Blocks exist in operator telemetry but not in a workspace-partitioned report the customer Admin can filter and export.
  • Seven-characteristic theatre. Advertising fairness, explainability, validity, and Safe because a secure tool gate shipped.
  • Instrument merger. Folding ISO/IEC 42001, the EU AI Act, or CSF certification language into the same switch.
  • Severity-slider confusion. Treating strict mode as “more compliant” rather than a different Secure-row posture with explicit UX cost.

The cheapest corrections are linguistic and structural: name the characteristic, show the coverage strip, write the event in the same request as the deny.

9. Related work and conclusion

9.1 Related work

Parent map. The companion paper on the NIST AI RMF suite locates secure and resilient inside seven characteristics and separates suite from complements. This paper assumes that map and asks what a workspace can enforce without lying about the rest.

NIST stack. AI 100-1 (functions and characteristics); AI 600-1 (generative and agentic risks); IR 8596 draft (Secure / Defend / Thwart under CSF); AI 100-2 (attack vocabulary); CSF 2.0; SP 800-53 as the control catalog when one is required.

Adjacent regimes. ISO/IEC 42001 remains the certifiable management system. The EU AI Act is binding risk-tiered law where it applies. Crosswalks are appropriate; identity with a product toggle is not.

Product gates. Plan-mode tool gates, workspace tool permissions, provider guardrails, and admission controls are prior art this pattern composes rather than replaces.

9.2 What this paper does not claim

We do not measure incident-rate differences between workspaces with and without a trust layer. We do not publish a control overlay or a complete ISO 42001 crosswalk. We do not evaluate model alignment, dual-use refusals, or environmental safety. Those belong under other characteristics and other Measure programs.

9.3 Conclusion

A toggle is not a Measure program. A workspace trust layer can still be a coherent object: one policy, enforcement that does not depend on model obedience, a coverage strip that admits what is off, and same-request events a reviewer can read.

That object operationalizes secure and resilient (and partial privacy in a stricter mode) for tool-using agents. It does not implement the AI RMF. It does not certify anything. Used with the suite map — and with the discipline not to absorb Safe, fairness, and explainability into the same switch — it is more trustworthy than a badge that claims the whole framework.

Acknowledgments

This paper is a structured reading of publicly available NIST and related standards documents and a description of a workspace-policy pattern for tool-using agents. It is not affiliated with NIST, does not constitute legal or compliance advice, and does not claim that any product implements the AI RMF or is certified to it.

Citation

@online{violet2026trustlayer,
  author = {Haigh, John},
  title = {The Workspace Trust Layer: Enforcing One Characteristic of the AI RMF for Tool-Using Agents},
  date = {2026-09-13},
  year = {2026},
  url = {https://www.violetai.ca/en/research/trust-layer/paper},
}