Proposed October 2026 inventory review: We recommend starting with a concrete question: which tools may open firm records, transfer information or take action? Consider a hypothetical document assistant with an approved drafting task. Before expanding its access, ask who owns the task and what information the assistant actually needs.
We recommend adapting the worksheet and six steps below to the firm’s work. Use them to record permissions, outstanding questions and the evidence reviewed. Have a named person decide what is acceptable before a tool receives additional access.
What the guidance supports
Use the three cited guides as background for this proposed worksheet. Ask the firm’s designated reviewer to decide which controls fit its work and which questions need specialist review.
The Govern section of NIST’s AI Risk Management Framework Playbook describes organizational policies and procedures for managing AI risk. It notes that unclear responsibilities and chains of command limit effective risk management.
The OWASP AI Agent Security Cheat Sheet recommends checking authorization in the component that executes an action, outside the assistant’s own context. It also recommends security testing before production and after material changes to prompts, tools, memory, retrieval, policies or model providers.
The OWASP Logging Cheat Sheet recommends collecting enough information for the intended monitoring and analysis. It identifies when, where, who and what as necessary event information, and says the intended purpose should guide how much is logged.
We recommend using the inventory to make decisions visible: who reviewed the evidence, which access they accepted and which questions remain unresolved. Ask the firm’s responsible reviewers to determine its confidentiality, monitoring and records requirements.
The inventory worksheet
Use one row per tool, skill, plugin or automation. Include the obvious items (a general chat assistant, a drafting tool, an intake assistant, a coding agent) and the easy-to-forget ones: browser extensions, meeting note-takers, CRM add-ons and workflow automations someone built on their own.
Record these proposed fields for each inventory row:
- Record the tool’s name, vendor and version.
- Record a named person who owns the business task and can coordinate a review.
- Record who installed or connected it, and when.
- List the particular folders, matter collections, inboxes, calendars or other records it is allowed to open.
- Record outgoing destinations, what information may be sent and the vendor’s documented storage arrangements. Mark unknown details as unresolved.
- List each permitted action and assess its data scope, recipient and consequences. Review reading, drafting, record updates and external communications separately.
- Define which actions need approval and who may approve their exact details.
- Record which activity details are logged, where the record is kept and who may inspect it.
- Record the firm’s approved retention and export decision, including who made it.
- Record the last check, its evidence and which changes trigger another review.
For a hypothetical test row, record an intake assistant that reads only fictional inquiries and a test calendar. List its permitted test destination and mark unanswered vendor-retention questions as unresolved. Define drafting a reply and sending a message as separate actions. We recommend keeping real client information outside that test while the responsible reviewer resolves the questions.
Six steps to fill it in
1. List everything and name an owner
Start from approved purchasing records, extension lists, sign-in administration and automation accounts. Ask staff which tools they use for firm work, including tools connected through another product. Record a named owner and ask that person to confirm the task. If ownership is unclear, assign the question for review before expanding access.
2. Record reading and outgoing transfers separately
We recommend keeping reading permissions and outgoing transfers in separate fields. A tool with read-only access could still send information elsewhere, depending on its design and configuration. Ask what it can open and where that information may travel; a read-only label does not establish the answer to the second question.
Start with vendor documentation and contract terms for both columns, and mark each entry as documented or verified. Then apply least access: point a tool at the narrowest folder, account or role that does its job, not at an owner login or a whole drive.
3. Test with fictional records
Use invented, non-client records for the first test in an environment approved for that purpose. If the firm later proposes de-identified material, require its designated reviewer to approve the material and intended destinations first. Ask a qualified operator to observe connections and record destination domains, timing and approximate volume. Compare the observation with the vendor’s documentation.
Record what was attempted and what completed, the tested version and the observation period. Identify what the check could not reveal, including the contents of encrypted traffic or later vendor processing. Treat a quiet session as a bounded observation. Set another check after material changes, rather than treating one test as a general safety result.
4. Treat skills, plugins and shared setups as code
Review each skill, plugin or shared setup before installing it. Check its requested permissions and dependencies, approve only the scope needed for the task, and record the version reviewed. Where version pinning is supported, use it alongside a documented change-review process. Test with fictional records and keep the reviewer’s decision. Treat marketplace descriptions as claims to check.
5. Define actions and where approval is checked
Define authorization for reading, drafting, changing records and external actions. Assess each action by its data scope and consequences; do not assume an internal note or record update is harmless or easily undone. Require access checks for reading as well as writing. For actions the firm classifies as consequential, require approval tied to the exact proposed action.
For a related proposed design, see how to enforce refusals outside the model. Ask the implementer to show where permissions and any required approval are checked before an action executes. Include a test where the recipient or proposed action changes after approval.
6. Decide what gets logged, exported and retained
We recommend deciding what information the activity record should contain before collecting it. Name the reviewer who approves that purpose and the people permitted to inspect the record.
Record the actor, time, action, target reference and outcome where the firm has approved those fields. Keep credentials and unnecessary client content out of routine activity records. Ask the reviewer to justify any full-content collection and approve its access restrictions before enabling it.
Ask the firm’s designated reviewer to approve the proposed monitoring scope and involve its counsel or privacy adviser when needed. Record the decision and unresolved questions. Do not treat this worksheet as authorization to monitor staff or copy client information.
We recommend exporting only approved material for a defined purpose. Review instructions and configuration files for secrets or client information before copying them. Record the destination, permitted readers, retention period and disposal decision. For transcripts, ask the responsible reviewer whether an export is needed and permitted. Avoid creating a second unmanaged copy merely to preserve a tool’s history.
Recommended acceptance tests
Use these proposed acceptance checks, adjusted to the firm’s task and risk:
- Confirm a named owner and separate reading and outgoing-transfer entries. Mark each entry as documented, observed or unresolved.
- Record an approved test using fictional data and identify the observation’s limits.
- Test that an action requiring approval is blocked without it, and when its approved parameters change.
- Test that an undefined tool or action is stopped for review.
- Check that the activity record answers the approved questions without adding unnecessary client content.
- Confirm that retention and export decisions have an accountable reviewer.
Decide whether an unresolved item warrants restricted access, test-only use or a pause while it is investigated. Record the reason, responsible person and next action. We recommend making that decision according to the data and consequences, rather than a fixed number of failed checklist items.
Common pitfalls
- Record reading permissions and outgoing transfers separately. Ask for evidence of both before deciding whether the proposed scope is acceptable.
- Use fictional test records and approved destinations. Check the test environment itself before inviting staff to use it.
- Set a review cadence suited to the task and risk. Also define which material changes to permissions, prompts, tools, data sources or providers require another check.
- Consider dedicated accounts or clearly scoped roles. Ask the implementer how a reviewer can distinguish the tool’s activity from a person’s activity, and test that explanation.
- Include note-takers, browser extensions and small automations. Record their actual permissions rather than assuming a limited task means limited access.
- Ask the firm’s responsible reviewer which requirements apply to its work before adopting another organization’s rule or checklist.
What this guide does not establish
Use the inventory as a dated record of permissions, evidence and decisions. Keep unknowns visible, assign follow-up and update the record when the setup changes. Our interpretation is that this may make a review more concrete; it does not establish that a tool is safe, that an incident occurred or that the firm has lost inquiries or revenue.