Restricted Vault

Access-controlled storage for sensitive operational inventories: privileged-account rosters, network topology diagrams, secure-configuration workbooks, asset inventories with serial numbers. OrgAdmin-only by default, with an optional per-document allowlist for specific non-Admin readers and field-level masking for designated keys. Every read is audit-logged.

Why a separate surface

TATER's three existing documentation surfaces are designed for team-wide visibility:

  • TATERpedia - generic methodology, shared across the org.
  • Configuration Documentation - per-org system state, readable by Auditors+ at minimum.
  • Business Documentation - SOPs and process docs, broadly accessible by design.

None of those are appropriate for material like a privileged-account roster, a full network topology diagram, or asset inventories listing serial numbers. Putting that content into a broadly readable surface creates an attacker roadmap and audit-trail gap. The Restricted Vault closes that gap with three guarantees:

  • Read gate. OrgAdmin role required, OR the caller's Entra OID must be on the document's accessAllowlist. Auditor and Viewer roles have NO read access whatsoever.
  • Every read is audit-logged. Not just create/update - every single fetch, with the caller identity, the document id, and whether the content was masked. Denied reads are also logged. This is the principal differentiator vs. the other doc surfaces.
  • Field-level masking. Non-Admin allowlist readers get sensitive keys (account UPNs, serial numbers) replaced with ***-LAST4. Admins always see full content.

Document schema

FieldTypeNotes
titlestringRequired. Up to 300 chars.
categorystringGrouping label - "Privileged Access", "Network", "Asset Inventory", etc.
descriptionstringShort purpose statement. Up to 5,000 chars.
bodymarkdownNarrative content (network diagram caption, workbook executive summary). Up to 200KB.
dataJSONOptional structured payload - inventory rows, account tables, etc. 1.5MB cap.
attachmentobjectOptional file pointer ({fileName, blobName, contentType, sizeBytes}). Admin-only blob fetch.
accessAllowliststring[]Entra OIDs granted READ beyond OrgAdmin. Max 200.
maskedFieldsstring[]Dot-path patterns under data to mask for non-Admin readers. Max 100.
linkedControlsstring[]Control IDs this document supports/evidences.
linkedRisksstring[]Risk IDs this document relates to.

Field-level masking syntax

Each entry in maskedFields is a dot-separated path under the data blob, with * matching any array index. The masking replaces the targeted value with ***-LAST4 (last 4 characters preserved; values shorter than 5 chars become ***).

Examples for typical inventory shapes:

{
  "data": {
    "rows": [
      { "host": "WS-001", "serial": "SN1234567890", "user": "alice@corp.com" },
      { "host": "WS-002", "serial": "SN0987654321", "user": "bob@corp.com" }
    ]
  },
  "maskedFields": ["rows.*.serial", "rows.*.user"]
}

A non-Admin allowlist reader gets back:

{
  "rows": [
    { "host": "WS-001", "serial": "***-7890", "user": "***-.com" },
    { "host": "WS-002", "serial": "***-4321", "user": "***-.com" }
  ]
}

An OrgAdmin sees the full unmasked content. The masking happens at the API layer - clients never receive the raw values for non-Admin readers, so it's safe against client-side bypass.

API reference

MethodPathAuthNotes
GET/api/vaultJWT - any roleReturns docs caller can read (OrgAdmin sees all; allowlist users see entries listing their OID). Heavy body/data stripped. List call audit-logged.
GET/api/vault/{id}JWT + canReadFull document. Audit-logged on success AND denial. Returns masked data for non-Admin allowlist readers.
POST/api/vaultOrgAdminCreate.
PUT/api/vault/{id}OrgAdminUpdate. Partial fields supported.
DELETE/api/vault/{id}OrgAdminSoft delete (sets status='archived' - the audit trail must remain queryable).

MCP tools

Four tools cover the full lifecycle for agentic admins (Claude, Copilot) authoring restricted inventories from a chat:

  • list_restricted_vault - inventory the store. Returns titles + flags; heavy content omitted.
  • get_restricted_document - fetch one. Every call audit-logged.
  • create_restricted_document - Admin-only. Author from a conversation.
  • update_restricted_document - Admin-only. Partial-update by id.

Recommended use cases

  • Privileged-account roster. Body = narrative on procurement / rotation cadence; data = JSON array of {role, upn, justification, lastReviewed}; maskedFields = ["accounts.*.upn"] for non-Admin allowlist readers.
  • Network topology diagram. Body = markdown caption + ASCII summary; attachment = the actual diagram PDF/PNG; allowlist = network engineers who aren't admins.
  • M365 SCC workbook. Attachment = the .xlsx; body = executive summary; linkedControls to the controls evidenced.
  • Asset inventory. data = JSON rows with host / serial / user; maskedFields = ["rows.*.serial"].

What's not in Phase 1

  • Dedicated TATER Security UI for browse + author (this ships in a follow-up; today the surface is API + MCP only).
  • Direct file upload + blob URL generation (the schema supports the attachment pointer; full upload UX is Phase 2).
  • Structured-table editor for inventory-style data blobs (Phase 2).
  • Per-doc allowlist UI for granting reads to specific OIDs (Phase 2; today set via accessAllowlist[] in the API/MCP payload).

Last updated: 2026-06-04. ADO #585.