The set of decisions where AI architecture, access, data flow, and governance are defined before deployment. In practice, it is where security can still shape the system. Once those decisions are locked in, later review can only reduce risk rather than design it out.
Expanded Definition
An AI design table is not a single vendor template or a formal standards term. It is a practical planning artefact used to record the security-critical decisions that shape an AI system before build and deployment. At NHI Management Group, this includes choices about model boundaries, data sources, tool access, logging, human approval points, and whether an AI agent can act independently or only recommend actions.
The design table matters because AI risk is often introduced long before runtime. It captures governance decisions at the moment they are still reversible, which is especially important when the system will handle secrets, personal data, or privileged workflows. A strong design table should reflect controls aligned to sources such as NIST SP 800-53 Rev 5 Security and Privacy Controls, even if the organisation uses a lighter internal format.
Definitions vary across vendors and teams, so the term should be treated as a governance aid rather than a universal standard. In practice, it sits between architecture review, threat modelling, and control selection, with enough detail to answer who can do what, with which data, under what approval. The most common misapplication is treating the AI design table as a post-build checklist, which occurs when teams complete it after the system has already been integrated with sensitive tools and live data.
Examples and Use Cases
Implementing an AI design table rigorously often introduces review overhead, requiring organisations to weigh faster delivery against clearer control over model behaviour, access, and data exposure.
- A security team maps which prompts may include customer data, then decides whether redaction, approval, or data minimisation is required before the system reaches production.
- An engineering group documents whether an AI agent can call ticketing, payment, or cloud administration tools, and whether each action requires human confirmation.
- A governance team records the model source, logging approach, retention period, and escalation path for unsafe outputs, using guidance consistent with NIST AI Risk Management Framework.
- A product team defines which identities, including non-human identities, are allowed to authenticate to APIs used by retrieval pipelines and orchestration services.
- A compliance team reviews whether the intended use fits internal policy before any training or fine-tuning begins, especially where regulated data or high-impact decisions are involved.
In higher-risk deployments, the table can also capture whether the system is intended to assist, recommend, or execute. That distinction is crucial when an AI agent has delegated authority, because the wrong assumption about autonomy can turn a workflow control into a privilege escalation path. For technical teams working on tool-enabled systems, the design table is often the first place to align with OWASP Top 10 for Large Language Model Applications and related threat scenarios.
Why It Matters for Security Teams
Security teams care about the AI design table because it is where hidden assumptions become visible. If access control, data boundaries, or approval flows are left undocumented, later testing can only find problems after the system has already been shaped around risky defaults. That leads to brittle compensating controls, unclear ownership, and weak auditability.
This concept intersects strongly with identity and NHI governance because AI systems increasingly rely on service accounts, API keys, workload identities, and delegated tooling. A design table that omits those identities can leave privileged access unmanaged, especially when an AI agent is granted execution authority. Security teams should therefore treat the table as a decision record for identity, data, and action boundaries, not as a purely product document. Where regulated personal data is involved, privacy handling and access traceability should also be aligned to identity assurance guidance such as NIST SP 800-63 Digital Identity Guidelines.
Organisations typically encounter the consequences only after a model begins leaking data, calling the wrong tool, or acting on an overbroad credential, at which point the AI design table becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST AI 600-1, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF defines governance practices that fit early AI design decisions and risk ownership. | |
| NIST AI 600-1 | The GenAI profile supports documenting generative AI risks, controls, and deployment assumptions. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance maps directly to tool access, autonomy, and unsafe action boundaries. | |
| NIST CSF 2.0 | GV.RM-03 | Risk management governance supports documenting security decisions before system release. |
| NIST SP 800-63 | IAL2 | Digital identity guidance is relevant when AI workflows depend on verified human or workload identity. |
Set identity assurance requirements for users and service identities that can influence AI actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
