On 29 September 2026, NIST’s National Cybersecurity Center of Excellence published an update on comments received for its Software and Agentic AI Identity and Authorization concept paper. The update identifies software development as the project’s first implementation use case, in collaboration with its DevSecOps work. See the NCCoE announcement.
This is work on an evolving project, not a newly issued certification for database products. Its relevance to software teams is concrete: an agent that can retrieve information or call tools needs an identity and permissions that the application can enforce.
Relevance does not establish permission
Imagine an internal developer assistant answering a deployment question. A document may be highly relevant to that question and still belong to another customer’s environment. A search engine’s relevance score cannot decide whether the requesting user is allowed to see it.
The application needs to know who requested the answer, which resources they may access and what the agent is permitted to do with them. Retrieval, generation and tool execution are different steps. A read-only search permission should not accidentally become authority to change a deployment.
Where OriginChainDB can help an application
An application can use OriginChainDB records for approved knowledge and operational metadata, FTS for exact terms, and vector retrieval for semantic candidates. Its supported access controls should be configured and tested for the intended principals and resources. The application should also verify authorization before passing retrieved text to an external model or returning it to a user.
This is an integration pattern, not a claim that OriginChainDB is part of the NCCoE project, offers a complete agent identity platform, or automatically authorizes every action in an agent framework. Tool gateways, model orchestration and approval rules remain separate responsibilities.
Give the first assistant a narrow job: read approved deployment documentation and cite the source. Keep administrative credentials outside prompts, client bundles and logs. If an action-capable agent is introduced later, define its resource scope and action permissions independently of the retrieval feature.
Build a small authorization test set
Create synthetic documents for two teams. Ask the same question as a member of each team and as an account with no document access. The relevant document may be the same by wording, but the allowed evidence must differ. Confirm that blocked content does not leak through snippets, titles, citations or debugging output.
Include a document containing text that tries to instruct the agent to ignore its rules. Retrieved text is evidence, not a new source of authority. The application should keep its system instructions and authorization logic outside that content.
Finally, remove access and repeat the test. A policy that works only at initial sign-in is not enough if the application keeps serving cached evidence after access changes. Decide how permission and content changes invalidate the relevant caches, then verify that behavior.
What a good first outcome looks like
The assistant answers an allowed question with a source, refuses or escalates an unsupported request, and produces a record that identifies which permitted evidence was used without exposing secrets. Those outcomes can be tested before adding more models or broader tool access.
Read the OriginChainDB documentation for the current data-access and retrieval surfaces, and follow the NCCoE project for subsequent developments. The architecture in this article is an original proposal for software teams; no customer outcome, certification or benchmark is implied.
