Key takeaways
- Decide what becomes shared memory: identify who can accept a proposed fact from a conversation into shared knowledge.
- Ask for observable evidence: inspect allowed and rejected writes, later retrieval, and the resulting tool decision.
- Approve a clearly defined workflow: name its sources, users, agents, and allowed actions.
A security review should show who can save, retrieve, and act on shared memory. Follow one example from an untrusted source through approval, later retrieval, and any resulting action. This makes the decisions between storage and use visible.
Start with the authority being granted
Ask the application owner to show how a coding assistant retains an approved project convention. Identify who supplies and approves it, which agents may retrieve it, and what actions they may request. A project fact must not become a grant of additional permissions.
The OWASP AI Agent Security Cheat Sheet discusses memory isolation and validation. Use those concerns to structure the review, then require evidence from the implementation your team will actually operate.
Request a small evidence packet
A practical review packet can contain the following five records. These are proposed review artifacts, not capabilities automatically supplied by a memory product.
| Record | What the reviewer should be able to establish |
|---|---|
| Source sample | Which message or document introduced the candidate, and which trust level it carries |
| Promotion decision | Which rule or reviewer accepted the specific fact, with its scope and version |
| Retrieval result | Which identity requested it and whether current access allowed its return |
| Action decision | Which application control allowed or denied the requested downstream operation |
| Correction exercise | How the team withdrew the record and checked affected derived copies |
Use synthetic examples when preparing the packet. Retain only the identifiers and excerpts needed for the review; production transcripts and credentials add exposure without improving a simple boundary test.
Watch one rejected record move through the system
Create a harmless source sentence that asks the agent to ignore a project rule. The expected result is that the untrusted instruction may be retained only as clearly scoped source evidence; it is not promoted into authoritative memory or followed as a command. Record where the candidate is refused, how the refusal appears to its owner, and what a later session retrieves.
Next, have an authorized owner approve an ordinary convention. The intended agent should find the accepted version, while a user or agent outside its permitted scope should be denied. This confirms the system supports useful memory rather than rejecting every write.
Then withdraw the record or revoke access. Check that later retrieval and consequential tool calls no longer rely on that record or access grant, including through relevant copies.
Place AKB in the reviewed architecture
Dnotitia AKB is a candidate for shared knowledge accessed by agents through MCP. In this review, its role is the knowledge destination. The surrounding application still needs a promotion policy, identity-bound retrieval, and independent authorization for consequential tool calls.
Use the selected release's documented configuration when evaluating storage, version history, and access behavior. Keep collection and automated curation as separately identified components. If the proposed configuration includes external services, list their data paths and permissions in the same evidence packet.
End with a decision that has an owner
Approve the workflow when the allowed and denied cases pass and an owner can correct or withdraw memory. For each failure, name the control to fix, its owner, and the result needed to pass a retest.
The NIST AI Risk Management Framework provides broader governance context. The final approval here belongs to your organization's process and the evidence collected for this particular workflow.