Enterprise AI Governance Framework: 9 Platform Requirements

Enterprise AI governance is usually treated as a document: a policy, a risk register, a charter. An enterprise AI governance framework such as ISO/IEC 42001 or the NIST AI Risk Management Framework tells an organization what to decide, and says much less about where those decisions get enforced when an employee or an agent sends a prompt.

This post treats it as a platform requirement: nine requirements a secure enterprise AI platform has to meet, grouped under security, governance and scalability, each with the rule behind it, its enforcement point, the evidence it emits and an evaluation test.

Disclosure: this blog is published by ASCENDING, which builds Jarvis, a governed AI platform.

An enterprise AI governance framework tells you what to decide; a platform has to enforce it

The NIST AI Risk Management Framework is voluntary guidance organized into four functions: Govern, Map, Measure and Manage. ISO/IEC 42001:2023 is the certifiable counterpart, specifying requirements for an AI management system.

Both are thorough on decisions, roles and documentation and thin on the record a single interaction should leave behind. That record is the platform’s job: only a component in the path of an interaction can say which model answered and whether the user was entitled to the documents used.

The buyer’s job is translation: each framework obligation becomes a platform requirement with a named enforcement point, evidence an auditor can sample, and a test that proves the control works before you sign.

Key requirements for enterprise AI platform security

Requirement 1: identity from the enterprise IdP, with deprovisioning

The platform must not keep its own user directory: sign-in runs through the corporate IdP over OpenID Connect and account lifecycle arrives through SCIM, so an HR termination removes AI access the way it removes email.

Test: disable a test user in the IdP, then try to sign in, resume an open session and call a connected tool under that user’s earlier consent; all three should fail without platform-side action.

Requirement 2: least privilege and access parity, including agents

NIST SP 800-207 frames zero trust around protecting resources, not network segments, with authentication and authorization as discrete steps before any session is established. Whatever grant the platform holds for a user must be scoped to what that user can already do in the source system; the AI layer must not become a second route to broader permissions.

Secure agentic AI workflows apply the same rule through workload identity: the MCP authorization specification requires servers to validate that a token was issued for them as its intended audience and forbids passing tokens through to upstream APIs, because one broad token shared across a multi-step workflow erases the separation of duties the source systems enforce (OWASP’s Excessive Agency, LLM06). Enterprise AI agent security best practices follow: authorization per tool call, not per session; a versioned tool allowlist per agent role; and hard stops on the write path (value thresholds, rate limits, a kill switch) that log their own trips as evidence.

Test: ask the AI interface to change a record the test user can read but not edit at the source; the platform must refuse and log the refusal with user, tool and decision.

Requirement 3: guardrails on input and output for sensitive data

The 2025 edition of the OWASP Top 10 for LLM Applications, still current in September 2026, ranks Prompt Injection first and Sensitive Information Disclosure second; the first arrives with the prompt, the second leaves with the answer, so scanning has to cover the prompt, retrieved context and the response, with redact, block and flag configurable per data class.

Test: seed a test knowledge base with synthetic personal data and confirm redaction when it is pasted into a prompt, retrieved into context and echoed back by the model.

Enterprise AI governance requirements: policy, evidence and inventory

Requirement 4: policy bound to data classification and role, not tools

Classification comes first: legal and security agree which of public, internal, confidential and regulated data may reach which models, the context-setting the NIST AI RMF’s Map function asks for. Policy then attaches to tier and role, and chat, agents, MCP tool calls and knowledge-base queries all read it; a rule re-entered per tool will drift. NIST SP 800-53 assesses Access Control and Audit and Accountability as separate control families, so one layer should produce both the policy record and the audit record but store them as distinct evidence.

Test: move one role from internal to confidential and confirm that chat, an agent workflow and a direct tool call all change without per-tool reconfiguration.

Requirement 5: a reconstructable per-interaction audit record

Define the minimum record: human principal, model requested and model that actually responded, prompt or configuration version in force, tools called and documents retrieved, output, disposition and timestamp. Store it append-only; redact sensitive fields rather than switch capture off.

Provider logs are not enough: Amazon Bedrock model invocation logging is off by default, captures request and response bodies only once a CloudWatch Logs or S3 destination is configured, and records the AWS principal plus caller-attached metadata, not the end user behind a shared role, the documents retrieved or the tool chain.

Test: take one interaction from yesterday and rebuild it from the log alone.

Requirement 6: an inventory that is a query, not a survey

ISO/IEC 42001 and the NIST AI RMF’s Govern function both expect the organization to know which AI it operates. A true inventory is a by-product of enforcement: when every model call and tool call crosses a gateway or is registered in a catalog, the inventory is a query over that traffic. Direct SDK calls remain the blind spot, so ask for a report of unregistered traffic, not a promise of total coverage (enterprise MCP registry architecture covers the split).

Test: count the platform’s inventory rows against your SSO and procurement discovery; the difference is your shadow AI.

Scalability requirements: many models, teams and clouds, one policy

Requirement 7: multi-model routing without multiplying policy

Enterprises that run several providers find that each ships its own access controls, usage terms and billing model; governance configured per provider means every new model brings a new policy and log format. The requirement: policy is evaluated once, against identity and data class, and a routing rule picks the model; adding a model edits the routing table, not the policy.

Test: swap the model behind a workflow; the same guardrail should fire and the same log fields populate, only the model identifiers changing.

Requirement 8: per-team quotas, rate limits and cost attribution

Quotas and rate limits are preventive controls that only count if a blocked call is logged beside the calls that went through: a blocked attempt is proof the control fired, and a results-only log throws that proof away. COSO’s generative AI guidance expects monitoring for anomalies and unauthorized use; quota trip events are that monitoring in machine-readable form. Cost attribution needs the user or team identifier to survive shared gateway credentials to the token count; ask for usage by user, team and application.

Test: give a test team a small token budget, exceed it, and confirm the block, the alert and the log line for the attempt.

Requirement 9: the same controls in every environment

Residency is simplest when the platform runs in the customer’s own cloud account, so history, embeddings and logs stay inside a boundary the customer already governs. Provider commitments matter too: AWS documents that model providers cannot access Bedrock logs, prompts or completions, and Microsoft documents that Azure OpenAI prompts and completions do not train base models; verify both against current terms.

Where agents and tools already span clouds, execution stays put while one layer issues the policy decision and audit record in one schema: a workflow across AWS and Azure leaves one trail, not two (see orchestrating multicloud agentic workflows).

Test: ask where history, embeddings and audit logs live, in which region, under whose keys, and whether provider-side invocation logging is on, in writing.

Map each requirement to an enforcement point

Five things enforce the nine requirements: the identity provider, the governed access layer or gateway, the registry or catalog, the deployment model, and the model provider’s own controls.

Requirement	Rule or standard	Enforcement point	Evidence emitted
1. IdP identity, deprovisioning	OIDC, SCIM; HIPAA 164.308	IdP integration	Login and revocation events per subject
2. Least privilege, access parity, audience-bound tokens	SP 800-207; OAuth scopes; MCP authorization; LLM06	Access layer / gateway	Per-tool allow or deny with identity
3. Input and output guardrails	OWASP LLM01, LLM02	Access layer	Redact or block event per interaction
4. Policy by data class and role	NIST AI RMF Map; SP 800-53 AC family	Access-layer policy engine	Policy version at call time
5. Reconstructable record	EU AI Act Article 19; HIPAA 164.312; COSO	Gateway plus append-only store	Principal, both model IDs, prompt version, tools, output, disposition, timestamp
6. Inventory as a query	ISO/IEC 42001; NIST AI RMF Govern	Registry / catalog	Assets with owner, version; unregistered traffic
7. Multi-model routing, one policy	Internal policy	Access-layer router	Routing decision; model actually used
8. Quotas, rate limits, cost attribution	Budget policy; COSO monitoring	Gateway	Blocked calls; tokens per user, team, application
9. Same controls everywhere	Residency law, contracts; provider terms	Customer account; provider controls	Region, retention, provider logging config

Per-application logs (no common schema, blind to traffic that bypassed them) and provider console logs (which stop at the model call) both fail the evidence column. An existing API gateway, often sold as an enterprise-grade API security and governance platform, enforces authentication and rate limits on HTTP calls but never sees the prompt, the retrieved documents, the tool chosen or the model that answered.

AI governance for regulated industry deployment

Healthcare: HIPAA’s technical safeguards (45 CFR 164.312(b)) require audit controls over systems holding ePHI, and its administrative safeguards (45 CFR 164.308(a)(1)(ii)(D) and (a)(3)(ii)(C)) require regular review of activity records and termination procedures.

EU: the AI Act makes activity logging for traceability a high-risk obligation, and Article 19 requires automatically generated logs to be kept at least six months unless other Union or national law, notably data-protection law, provides otherwise. Per the Commission’s timeline at the time of writing, the Act became applicable on 2 August 2026, but after the AI Omnibus the high-risk obligations behind Article 19 apply from 2 December 2027 (Annex III uses) and 2 August 2028 (Annex I products): a design requirement today, a legal one then.

US banking: SR 26-2, the revised model risk management guidance the Federal Reserve, OCC and FDIC issued on 17 April 2026 to supersede SR 11-7, states in footnote 3 of its attachment that generative and agentic AI models are outside its scope, leaving their controls to the institution’s own governance practices, where COSO’s 2026 guidance on internal control over generative AI fits.

Practical rules: set log retention to the longest obligation you face; deploy inside your own account; require vendors by contract to state their AI Act classification and supply technical documentation; and ask whether the vendor’s AI management system is ISO/IEC 42001 certified, treating the certificate as evidence about their management system, not yours.

Enterprise AI governance platform features vs governed access platform features

Two product categories share the phrase “enterprise AI governance platform”. AI governance platforms, the category Gartner tracks, manage the paperwork: policy registers, risk assessments, model inventories and EU AI Act documentation. Governed access platforms, or AI gateways, enforce decisions on live traffic: identity, guardrails, routing and logging. A working program needs both: documentation without enforcement cannot be evidenced, and enforcement without documentation is logs nobody has mapped to a control.

The enforcement-side shortlist for enterprise-ready AI governance framework software is the nine table rows plus two items no framework names: a per-interaction log exportable with OpenTelemetry GenAI attributes such as gen_ai.request.model, gen_ai.response.model and gen_ai.tool.name (still at Development status; pin the version and see OTel observability for AI agents), and human approval gates for high-impact actions.

Where Jarvis fits, and what to verify during evaluation

Jarvis is ASCENDING’s own product.

The Jarvis Governed AI layer is documented as a shared layer beneath Jarvis Chat and Jarvis Registry with PII detection and DLP, role-based access control, SSO over OpenID Connect, SAML and OAuth, audit logs and LLM routing across chat, agents and MCP tool calls: the sign-in, guardrail, audit and routing parts of requirements 1, 3, 5 and 7. SCIM deprovisioning and classification-tier policy (the rest of 1 and 4) are not documented, so run those tests rather than assume them.

Jarvis Registry is documented as an MCP and agent gateway with tool-level access control, per-invocation RBAC and ACL checks, audit trails and discovery (requirements 2 and 6, plus the rate-limit and audit half of 8); the token-usage demo shows the usage view, but per-team budgets and a hard stop are not documented, so keep them in the test. Deployment in the customer’s own AWS or Azure environment is documented (requirement 9), and the AWS Marketplace listing describes an Enterprise tier adding security guardrails, audit capabilities and governance controls; confirm scope, log schema and retention.

Bring the nine tests to every vendor demo, Jarvis included, or contact ASCENDING to run them against one real workflow and identity provider.

References

• NIST. “AI Risk Management Framework”.
• ISO. “ISO/IEC 42001:2023 Artificial intelligence management system”.
• OWASP GenAI Security Project. “OWASP Top 10 for LLM Applications 2025”.
• NIST. “SP 800-207: Zero Trust Architecture”.
• AWS. “Amazon Bedrock model invocation logging”.
• Model Context Protocol. “Authorization”.
• eCFR. “45 CFR 164.312 Technical safeguards”.
• eCFR. “45 CFR 164.308 Administrative safeguards”.
• EU Artificial Intelligence Act. “Article 19: Automatically Generated Logs”.
• European Commission. “AI Act: regulatory framework for AI”.
• Federal Reserve Board. “SR 26-2: Revised Guidance on Model Risk Management”.
• COSO. “Guidance on Internal Control, including Achieving Effective Internal Control Over Generative AI (2026)”.

FAQ — Enterprise AI Governance Framework Questions Buyers Ask

What are the key requirements for an enterprise AI platform across security, governance and scalability?

Security: identity from the enterprise IdP with automatic deprovisioning, least-privilege access that mirrors each user's existing permissions in connected systems, and guardrails that inspect both prompts and responses for sensitive data. Governance: policy bound to data classification and role, a per-interaction audit record that can be reconstructed later, and a maintained inventory of models, tools and agents. Scalability: routing across multiple models under one policy, per-team quotas and cost attribution, and the same controls in every cloud or on-premises environment. Each requirement should have a named enforcement point and a test you can run during evaluation.

What is an enterprise AI governance framework, and how is it different from a governance platform?

A framework such as ISO/IEC 42001 or the NIST AI RMF defines what an organization must decide, document and review: policy, roles, risk assessment, evaluation cadence. A governance platform is software. Some products in that category manage the documentation (policy registers, model inventories, regulatory evidence); others, often called governed access layers or AI gateways, enforce the decisions on live traffic through identity, guardrails, routing and logging. A working program usually needs the framework plus both kinds of tooling, because documentation without enforcement cannot be evidenced and enforcement without documentation cannot be mapped to a control.

What features should an enterprise AI governance platform have?

For the enforcement layer, look for SSO with SCIM provisioning, role-based access per model, tool and knowledge source, PII and DLP scanning on input and output, a structured per-interaction log that records the user, the model requested and the model that responded, the tools and documents touched and the outcome, model routing rules, per-team quotas and rate limits, human approval gates for high-impact actions, and the option to deploy inside your own cloud account. Ask for a log export and a demo of each control rather than a feature list.

How does AI governance change for regulated industry deployment?

The requirements stay the same but retention, residency and documentation get stricter. HIPAA's technical safeguards require audit controls on systems holding ePHI and regular review of activity records; the EU AI Act treats activity logging for traceability as a high-risk obligation and, in Article 19, requires automatically generated logs to be kept for at least six months unless other Union or national law provides otherwise; and SR 26-2, the US banking agencies' April 2026 model risk management guidance, places generative and agentic AI outside its scope, pushing controls onto the institution's own governance practices. Set retention to the longest applicable obligation, keep the deployment in your own account, and require vendors to state their regulatory classification and provide technical documentation.

What are the main enterprise AI agent security best practices?

Give each agent its own identity and short-lived, audience-bound tokens instead of one broad credential shared across a workflow; evaluate authorization per tool call rather than per session; keep tool allowlists per agent role under version control; put value thresholds, rate limits and a kill switch on the write path; log attempted actions as well as completed ones; and require human approval before actions with external consequences. These map to OWASP's Excessive Agency entry and to the audience-validation rule in the MCP authorization specification.

Can an existing API gateway serve as an enterprise-grade AI security and governance platform?

Only partially. An API gateway authenticates callers, applies rate limits and logs HTTP requests, which covers part of the identity and quota requirements. It does not see the prompt, the retrieved documents, the tool the agent chose or which model actually answered, so it cannot apply data-classification policy, redact sensitive content or produce a reconstructable AI audit record. Treat it as one layer beneath a governed access layer, not as a replacement for one.