Why Enterprise AI Needs More Than SSO and Admin Controls

Enterprise AI governance has to cover what the AI does, not just who is allowed to sign in. Single sign-on, role management and an admin console answer an important question — which people may use a tool — and every enterprise needs them. But AI introduces new questions that identity controls cannot answer: which models and providers a project may use, how much it may spend, what prompts and responses are logged and for how long, which AI actions need a human decision and at what risk level, what evidence is kept of what the AI did, and what happens when a control cannot be checked. Ethen documents controls for each of these in its Gateway and Platform, labeled with their current maturity. This article explains why each matters, what Ethen provides today, what is not yet in scope, and questions to ask any enterprise AI vendor.

Key takeaways

• Identity governs people, not AI behavior. SSO is necessary and insufficient.
• AI needs five more layers. Model eligibility, spend, data handling, actions and approvals, evidence and change.
• Fail closed. If a control cannot be checked, the request should be denied, not allowed.
• Agents raise the stakes. Once AI acts, approvals and audit matter as much as access.
• Ask about maturity. Documented controls, independent review and compliance claims are different things.

Why SSO is not enough

Single sign-on solves a real problem: it lets an organization control who can access a tool, from one place, with its existing identity provider. Admin consoles add roles, permissions and user management. Those controls were designed for software that does what people tell it to, one action at a time.

AI changes the picture in three ways.

AI makes choices on the user's behalf. Which model to call, which provider to send data to, how many tokens to spend, which tool to use next. A signed-in user does not approve each of those choices individually.

AI handles data differently. Prompts can contain sensitive material, and responses can echo it. Where that content goes, whether it is logged, and how long it is kept are governance decisions, not identity decisions.

AI increasingly acts. Agents send messages, update records and make purchases. Once an AI system takes actions, the question is not only who is signed in but which actions need a person's decision.

Recent industry surveys of organizations deploying AI agents report that many cannot enforce purpose limits on agents or reliably stop one once it is running. Whatever the exact figures, the pattern is clear: identity controls are being asked to do a job they were not designed for. Figure 1 shows the gap.

The layers of enterprise AI governance

Effective governance of enterprise AI has six layers. Identity and administration is the first. The other five are specific to AI. Figure 2 shows them together.

Model and provider eligibility

Different AI providers have different terms, data practices, regions and capabilities. An enterprise may approve some providers for some projects and not others. Governance needs a way to say "this project may only use these providers", enforced at the point where requests are routed.

In Ethen's Gateway, projects can configure a provider allowlist. Once a project has any allowlist entries, only explicitly allowed providers are eligible, and providers without an entry are denied by default. How the Gateway decides which models are eligible for a request is described in How Ethen Gateway Chooses an Eligible Model.

Spend

AI costs scale with usage, and usage can spike. Governance needs budgets that are enforced, not just reported. Ethen's Gateway supports per-project limits by day and by month, in estimated cost or tokens, and rejects further requests from a project once its limit is exceeded. Requests are also bound to a specific project through their key, so spending is attributed correctly; see How Ethen Gateway Binds API Requests to Projects.

Data handling

Enterprises need to decide what AI traffic is logged and retained. Ethen's documented default logging mode records metadata only — tokens, latency, cost, status and error codes — and not message content or responses. Projects can choose to log content, and a zero-data-retention mode writes only metadata regardless of other settings. These settings are per project, and the documentation is explicit that zero retention is a project-level configuration, not a global guarantee. See the data handling documentation.

Actions and approvals

When AI acts, governance needs to decide which actions require a person's decision. Ethen's documented approval policies let an organization set risk-level thresholds above which approval is required, block certain risk levels outright, allow low-risk actions to run automatically up to a set count, require a written justification for approval, and route unresolved approvals to an escalation contact. Approvals are bound to the specific action they authorize. See the approval governance documentation, and the reasoning in Why Ethen Keeps Human Approval in the Loop.

Evidence and change

Finally, governance needs evidence: a record of what the AI did that can be reviewed and exported, and a way to test changes — such as a new model version — before they reach real work. Ethen documents audit entries and evidence packages with export, described in the evidence and audit documentation. On the change side, Ethen Research Lab's Model Change Assurance research note sets out why model upgrades should be tested against real work before rollout, and we explain the product consequence in Why Ethen Doesn't Always Use the Newest Model.

How agents change the governance problem

Governance designed for chat assistants is not enough for agents, for four reasons.

Agents act with delegated identity. When an agent sends an email or updates a record, it acts with access a person granted. Identity systems record that the person signed in; they do not record that an agent, three steps into a task, decided to use that access in a particular way. Governance has to connect each agent action to the person and the decision that authorized it.

Agents run without anyone watching. A chat assistant waits for the next message. An agent continues working. Controls that rely on a person noticing something odd — the traditional backstop — are weaker when no one is looking. That makes enforced limits, such as budgets and blocked action types, and the ability to stop a running agent, more important.

Agents read untrusted content. An agent browsing the web or processing email reads material written by people outside the organization, some of whom may try to manipulate it. Bounding what an agent can do limits what that manipulation can achieve, which is why approval policies by risk level matter.

Agents chain actions. One request can lead to dozens of tool calls. Governance that evaluates only the initial request misses everything that follows. Each consequential step needs its own check and its own record.

These are the reasons approval policies, evidence records and fail-closed controls move from optional to essential as organizations adopt agents. We describe the broader principle in What We Mean by Responsible Autonomy.

Fail closed: what happens when a control cannot be checked

One governance property is easy to overlook and critical in practice: what happens when a control cannot be evaluated. If the system that stores the provider allowlist or the budget is unavailable, should requests proceed or stop?

A control that fails open — allowing requests when it cannot check them — is only a control when everything is working. Ethen's documented policy is to fail closed: if the backing storage for the provider allowlist or budget checks is unavailable, access is denied rather than allowed, with a bypass reserved for local development. Figure 3 shows where these checks sit in a single request.

Failing closed has a cost: an infrastructure problem can block legitimate work. For governance controls, we think that is the right default.

Credential isolation

AI platforms hold credentials for AI providers and other services. Governance needs those credentials isolated so that one project's keys cannot be used by another. Ethen documents three forms of isolation: provider credentials brought by a customer are encrypted and scoped to a single project; Gateway API keys are bound to one project and one environment, with cross-project access rejected; and credentials for local models on the desktop are stored separately from the Gateway's. See credential management.

What is not yet in scope

Honest governance writing includes what is missing. Ethen's enterprise controls are documented as alpha. According to our documentation, enterprise single sign-on with directory provisioning, and data residency, are outside the scope of the current release. Independent security review of the enterprise controls has not yet been completed, and claims that depend on it are marked as requiring review in the documentation itself.

That may seem an odd thing to say in an article arguing that enterprise AI needs more than SSO. It is the point. Governance is a set of separate capabilities, each with its own maturity. A buyer should be able to see exactly which exist, which are documented, which have been independently reviewed and which are planned — and a vendor should say so plainly.

Standards and frameworks

Several frameworks help organizations structure AI governance. The NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing AI risk. ISO/IEC 42001, published in 2023, specifies requirements for an AI management system that organizations can integrate with their existing management systems. The OWASP Top 10 for Large Language Model Applications lists the most common security risks in applications built on language models, such as prompt injection and excessive agency.

These frameworks describe what an organization should do. Product controls like those above are how a platform helps it do so. Neither Ethen nor this article claims certification against any of these frameworks.

Questions to ask any enterprise AI vendor

Whether you are evaluating Ethen or another platform, these questions get past identity features to AI governance.

1. Can we restrict which models and providers each project may use, and is that restriction enforced at routing time?
2. Can we set budgets that block requests, not just report spend?
3. What is logged by default? Is content logged? Can we turn content retention off per project?
4. Which AI actions require human approval, and can we set that by risk level?
5. Is each approval bound to a specific action, or does it authorize whatever follows?
6. What evidence of AI activity can we export for audit?
7. What happens when a control cannot be checked — does the system fail open or closed?
8. How are model changes tested before they reach our workloads?
9. Which of these controls have been independently reviewed, and which are self-described?

A worked example

The following example is illustrative. A legal team wants to use AI to summarize contracts and draft emails to counterparties.

The platform owner creates a project for the legal team. They restrict the project to two approved providers, set a monthly budget, and set logging to metadata only, so contract text is not retained in request logs. They set an approval policy: summaries run without approval; any email to an external address requires approval with a written justification; and deleting files is blocked. Audit export is scheduled monthly for the compliance team.

Three months later, one approved provider releases a new model version. Rather than switching the project automatically, the platform owner runs the team's typical tasks against the new version first and compares results before allowing it. Meanwhile, a storage outage briefly makes budget checks unavailable; requests are refused for a few minutes rather than allowed without limits.

None of these controls involves single sign-on. All of them are part of governing what the AI does.

Tradeoffs and limitations

More controls, more configuration. Each layer needs decisions. Good defaults help, but governance takes work.

Fail-closed blocks work during outages. We accept that for governance controls.

Controls do not prove compliance. Product controls support compliance programs; they do not certify them.

Maturity varies. Ethen's enterprise controls are documented as alpha, and some capabilities are outside the current release scope.

FAQ

What controls does enterprise AI need beyond SSO? Model and provider eligibility, enforced budgets, data logging and retention settings, approval policies for AI actions, exportable evidence, fail-closed behavior and testing of model changes.

How do you govern AI agents in a company? Bound what they can do, require approval for consequential actions by risk level, keep a record of every action, make sure they can be stopped, and test changes before rollout.

What should an enterprise AI platform log? At minimum, metadata such as who, which project, which model, tokens, cost, status and errors. Content logging should be a deliberate per-project choice, with an option for zero retention.

Does Ethen support enterprise SSO? According to current documentation, enterprise single sign-on with directory provisioning is outside the scope of the current release.

Is Ethen certified against ISO/IEC 42001 or similar frameworks? No certification is claimed.

Related reading

• How We're Preparing Ethen for Private and Enterprise Deployments
• When an AI Gateway Helps
• How Ethen Gateway Binds API Requests to Projects
• Why Ethen Keeps Human Approval in the Loop
• Ethen enterprise controls documentation

References

1. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. https://doi.org/10.6028/NIST.AI.100-1
2. ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. https://www.iso.org/standard/81230.html
3. OWASP. OWASP Top 10 for Large Language Model Applications. https://owasp.org/www-project-top-10-for-large-language-model-applications/
4. Ethen Docs. Enterprise controls. https://upcube.ai/docs/enterprise/enterprise-controls
5. Ethen Docs. Data handling and retention. https://upcube.ai/docs/security/data-handling
6. Ethen Research Lab (2026). Model Change Assurance: Testing AI Upgrades Before They Reach Real Work. Research note. https://upcube.ai/resources/research/model-change-assurance