Start with inventory and privilege. Identify every model, agent, connector, and data source, then decide which actions truly need to exist and which should require approval or be removed. Without that baseline, policy, monitoring, and compliance controls are all built on incomplete assumptions.
Start With Inventory, Then Prove the Minimum Necessary Access
The first review is not a policy document or a compliance checklist, it is the production boundary itself. Organisations need a complete inventory of every model, agent, connector, plugin, API, dataset, and human approval path before they can judge whether GenAI is ready to ship. Once that picture exists, the next question is simple: which actions are truly required, which should be read-only, and which must require approval or be removed entirely?
This matters because GenAI failures often come from hidden reach, not just model quality. A harmless-looking assistant can become a production control plane if it can query sensitive systems, write records, trigger workflows, or call other tools without a tight allowlist.
What the Inventory Should Actually Contain
A useful review goes deeper than naming the model. Teams should document the model’s source, deployment location, connected tools, identity or service account, prompt and context inputs, output destinations, data classes exposed to it, and the business owner responsible for the use case. The same inventory should show whether the system can reach internal applications, external services, secrets, or customer data.
That inventory is the basis for deciding blast radius. If a connector can read from a shared workspace but also write into a ticketing system, the risk profile changes immediately. If an agent can chain multiple tools together, the review must treat the chain as one access path, not as isolated steps.
For that reason, the inventory should include any approval or escalation path that allows the system to do more than its baseline permissions. In practice, many production failures start when a team knows the model exists but has not mapped every place where it can act.
Why Inventory Leads to Safer Policy and Better Control Design
Policy only works when it is grounded in actual system behaviour. If teams do not know what the model touches, they tend to write broad rules that look reassuring but do not constrain real access. A complete inventory lets security and engineering decide where to apply least privilege, where to require human review, and where the safest answer is to block the integration entirely.
That review also determines what to monitor. Logs are far more useful when they are tied to specific model-to-tool relationships, rather than to a vague “GenAI usage” bucket. The same is true for compliance evidence: auditors and approvers need to see what was connected, why it was needed, and who accepted the residual risk.
For a useful baseline on governing GenAI risk before production, NIST AI 600-1 GenAI Profile is a strong companion because it emphasises governance, testing, provenance, and deployment risk management before broad release.
Risk and Threat Considerations
GenAI becomes risky in production when its access is broader than the organisation understands. The biggest exposure is not only incorrect answers, but unintended action: data leakage, overbroad tool use, privilege abuse, and hidden dependency on connectors or agents that were never formally reviewed.
Failure mechanism: An incomplete inventory leaves unseen model, agent, or connector paths in place, so approval, monitoring, and access controls are designed around a partial picture of the environment.
Impact: The organisation can overestimate its control posture, miss unauthorized data access or write actions, and discover only after deployment that a seemingly narrow GenAI use case has a much wider blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI 600-1, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | Generative AI Profile | GenAI production review depends on governance, testing, and deployment risk management. |
| Recommendation — Apply the GenAI profile to inventory system interactions before production release. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | A production review needs asset and use-case context to scope GenAI risk correctly. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | The question centres on privilege and permitted actions for GenAI components. | |
| GV.RM-01 — Risk Management Strategy | Inventory-first review supports risk acceptance decisions for GenAI in production. | |
| Recommendation — Document the GenAI operating context and ownership before approving deployment. Constrain model and agent access to the minimum required permissions. Base GenAI production approval on a documented risk strategy and residual-risk decision. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The answer explicitly asks what should be allowed and what should be removed. |
| Recommendation — Limit GenAI components to the minimum privileges needed for the use case. | ||
Practitioner Guidance
What to prioritise: Review every production-facing GenAI use case from the access side first. If you cannot list the model, its owners, its connectors, its data sources, and its allowed actions in one place, the deployment is not ready for policy approval.
What to verify: Confirm that each action is intentional, necessary, and bounded. A read-only assistant and an agent that can update records, trigger workflows, or retrieve secrets are different systems from a security standpoint, even if they share the same model.
Decision rule: If an action is not essential to the business outcome, remove it. If it is essential but high impact, require explicit approval, tighter logging, and a separate review of who can grant or revoke that access.
Practitioner takeaway: The first production gate for GenAI is not model accuracy, it is understanding exactly what the system can reach and do. Inventory and privilege come before policy because they define the real attack surface.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- What should organisations do before allowing AI-generated dependencies into production?
- What should IAM teams review before allowing MCP in production?
- What should organisations review before rolling IoT devices into production?