Enterprise AI Agents: Everyone Passes the Checklist

TL;DR: Every enterprise AI agent platform answers yes to the same procurement checklist: single sign-on, audit logs, role separation, scales horizontally. The checklist is not wrong, it is just unfalsifiable, because yes is the only commercially sensible answer and nothing on the form asks for evidence. We ran it against our own platform and published the results including the failures. Fifteen of our fifty one API routers emit an audit line. Nine of our sixty one node types pin a run to a single machine. We support OIDC and not SAML, and we have no SCIM at all.

Key Takeaways:

• The industry's own maturity model treats "we have SSO" as a middle tier, not a finished one. Okta's 2026 CISO survey defines that tier as standardized identity controls that still struggle with downstream agent permissions
• Two different questions are both called SSO for AI agents. One is how your team logs in, one is what credential the agent presents downstream. Vendors mostly answer the second, buyers mostly mean the first
• Audit logging has a location, and no procurement checklist asks about it. In a multi machine deployment an audit line emitted from inside the execution path lands on whichever host claimed the job
• Of our 61 node types, 52 can run on any machine in a cluster and 9 cannot. One pinned node anywhere in a workflow pins the whole run, including through sub-workflows
• Cluster weights are shares of the machines currently alive, not percentages of a hundred. Set three instances to 41, 26 and 33, turn one off, and the main instance is suddenly taking 61 percent

Table of Contents

• The Checklist Everyone Passes
• What an Enterprise AI Agent Platform Has to Answer
• Box One: Who Can Get In
• Box Two: What Got Recorded
• Box Three: Where It Actually Ran
• We Ran the Checklist on Ourselves
• How These Numbers Were Produced
• A Checklist You Can Run on Any Vendor
• What This Post Is Not
• Frequently Asked Questions

The Checklist Everyone Passes

I read twenty vendor pages about enterprise AI agents before writing this, and every one of them answered the same questions the same way. Single sign-on, yes. Audit logs, yes. Role based access, yes. SOC 2, in progress or done. Scales horizontally, yes.

The same five answers come back whether the product calls itself an agent platform or enterprise AI workflow automation, which is the first clue that the questions are doing less work than they look like they are.

That uniformity is not a conspiracy. It is what happens when a question can be answered with a word. No procurement form in circulation asks a vendor to show the thing, so nobody does, and a buyer ends up comparing five identical yeses.

The interesting part is that the security industry already knows this. Okta's Global CISO Insights 2026, a survey of 306 CISOs and security executives finalized in June 2026, places organizations on a four level maturity scale. The middle level, Defined, reads: "We have standardized identity controls (e.g., SSO, MFA) applied to known AI tools, but struggle with shadow AI or downstream agent permissions."

Read that again. Having SSO is the definition of the middle of the scale. It is a thing you have while still not knowing what your agents can reach. In the same survey, 47 percent said they can identify all the agents in their environment, 46 percent can control what those agents access, and 21 percent are governing them with shared credentials or broad permission service accounts.

This post is for the engineer who has to fill in the security questionnaire for an automation platform their team already chose, and who suspects the form is not asking the right things. It is not a buyer's guide and there is no vendor table in it.

I work on the product I am about to measure, which is a commercial interest and worth stating plainly. It is also the reason the numbers exist: I have a platform I can count and permission to publish the result, including the parts that make us look worse than our own marketing page does. Every figure below is either in the source, in the documentation, or cited to a third party.

What Heym is: Heym is a source-available, self-hosted AI workflow automation platform with a visual canvas for multi-agent pipelines, RAG and MCP. Every measurement in this post comes from its own source code and documentation, which anyone can read on GitHub. Where a control is missing or partial, that is stated as such.

What an Enterprise AI Agent Platform Has to Answer

Definition: An enterprise AI agent platform is a system for building and running autonomous workflows that satisfies an organization's identity, accountability and scale requirements, not only its functional ones. Three questions decide it: who is allowed in, what record exists of what they did, and which machine the work ran on.

The first two questions appear on every checklist. The third appears on none of them, and it is the one that quietly breaks the other two.

The third question is also the one that changes shape when you run the software yourself. On a self hosted AI agent platform there is no vendor operating the fleet on your behalf, so the machine boundaries are yours to draw, and so are the consequences of drawing them badly.

Box One: Who Can Get In

Two different questions are both called SSO

Search for sso for ai agents and the top result will explain that traditional single sign-on fails for AI agents, and that what you need is machine identity, ephemeral credentials and federated agent identity. That is a real subject and the page is not wrong. It is also answering a different question from the one on your questionnaire.

Both matter. They are not the same control and one does not imply the other. The SANS Institute's 2026 State of Identity Threats and Defenses survey, covering more than 500 security professionals, found 74 percent of organizations already run AI agents or automations that need credentials, while 92 percent fail to rotate machine credentials on a ninety day cycle. Perfect federated login for humans does nothing about that number.

If you want the formal version of this split, the National Institute of Standards and Technology treats federation as its own assurance dimension in SP 800-63C, separate from how strongly the original authentication was performed. The OWASP Gen AI Security Project covers the agent side in its State of Agentic AI Security and Governance report.

The rest of this section is about the first column, because that is what a platform can actually ship.

What a real OIDC integration has to refuse

Ours reads one thing from an administrator: an issuer URL. Everything else, the authorization endpoint, the token endpoint and the signing keys, comes from that provider's discovery document, as described in the OpenID Connect Discovery specification. No provider is hardcoded, so Keycloak, Okta, Entra ID, Auth0 and Google all connect through the same four fields. The client is confidential and the flow uses authorization code with PKCE, which is the pattern Microsoft documents for its own OIDC implementation.

None of that is interesting. What is interesting is what the integration refuses to do.

An identity provider returns a set of claims about the person who just authenticated. One of them is email_verified, defined in the OpenID Connect Core specification as a boolean asserting that the provider has taken steps to verify the address.

Our callback checks that claim with an identity comparison rather than a truthiness test, so a missing claim is refused exactly like a false one. There are four refusal codes in that path, and each is a decision somebody could have made differently:

• email_missing, when the provider returned no address at all
• email_not_verified, when it returned one it will not vouch for
• domain_not_allowed, when the address is outside the configured allowlist
• provisioning_disabled, when the person is unknown and automatic account creation is off

The second one is the account takeover path. If a platform claims an existing account on the strength of an unverified address, anyone who can get an identity provider to emit an arbitrary email can walk into someone else's account. Refusing costs you a support ticket. Not refusing costs you an incident.

Key principle: Single sign-on is not a login button, it is a set of claims you have decided to trust. The security of the feature lives entirely in which claims you refuse.

Account resolution then runs in a fixed order: the issuer and subject pair from a previous sign-in first, because that survives someone changing their email at the provider; then a verified email matching an existing account; then a new account, only if automatic provisioning is on and the domain is allowed.

The switch that can lock you out of your own instance

Every SSO feature eventually offers to turn off password sign-in. It is the right thing to want and it is also the fastest way to lock every administrator out of a system nobody can now get into.

Ours refuses to become available until three things are true at once. Single sign-on has to be enabled. A connection test has to have passed against the issuer that is actually saved, not a draft one you typed into the form. And at least one account in the administrator list has to still have a password, so there is a way back in.

The third condition is the one worth stealing. The other two check that the new door works. Only the third checks that the old door still opens.

When the switch is on, password authentication is refused on all three surfaces that mint or accept one: the login form, registration, and the consent page for MCP clients. Registration counts because it issues a password. Leaving it open would make the entire setting bypassable by anyone who can reach the sign up URL, which is a good example of a control that is 90 percent implemented being worth close to zero.

Box Two: What Got Recorded

I am going to be brief here, because we published a long treatment of audit trails in AI agent governance and I would rather link it than repeat it. That post covers what an audit line should contain, why over redaction is the right default, and why we deliberately leave the client IP out.

The short version on that last one: behind a load balancer the address is either the proxy's own or a forwarded header that anyone can set. A field that looks like evidence without being evidence is worse than an absent one.

What that post did not ask, and what no checklist asks, is where the line gets written. An AI agent audit log is usually discussed as a schema question, a list of fields somebody should capture. It is also a location question, and the location is the half that a growing deployment quietly changes underneath you.

Ours go to stdout as single self contained lines. Nothing is written to a database table. That is a deliberate trade: your existing log shipper owns retention, search and alerting, and we do not build a worse version of Splunk inside a workflow tool. Here is a real one, from the sign-in path described above:

audit action=auth.sso_login outcome=denied actor_email=someone@example.com reason=email_not_verified

Four fields, no ambiguity, and nothing in it that would hurt if it leaked. That is the whole design.

Now the number. We have 51 API router modules. Fifteen of them emit audit lines, across 128 call sites. That is 29 percent, and while the fifteen were chosen because they were obviously security relevant, I cannot tell you which of the other 36 should be on the list without reading them one at a time. Anyone who tells you their coverage is complete either has a much smaller API or has not counted.

Box Three: Where It Actually Ran

Here is the part that no vendor page we read covers at all, and the reason the first two boxes are not enough.

The moment your automation platform runs on more than one machine, every question in box two acquires a second half. Not just what was recorded, but on which host. Not just who acted, but where the record of it landed.

Definition: Execution placement is the rule that decides which machine in a multi-instance deployment is permitted to run a given workflow. It exists because some work is bound to one host, such as anything reading files from local disk or depending on software installed there, and a run that lands on the wrong machine fails in ways that are hard to read.

The instances do not talk to each other

Our own model is deliberately boring. Point a second instance at the same PostgreSQL database and it joins as a worker. The instances never open connections to each other. Postgres carries the work, so a worker needs no inbound port, no certificate and no route back to the first machine. It needs database access and nothing else.

One instance is main. It serves the UI, the API and file storage. Everything else is a worker. That role is separate from leader election: a single leader owns cron scheduling and crash recovery and can move to any instance within seconds, but the main role does not move, because file storage cannot move with it.

Which work cannot leave the first machine

This is the list every distributed system has and almost nobody publishes. Ours lives in one file with one entry per node type, and a test fails the build if a node is registered without one. There is no default, because a silent fallback is how you end up with a workflow that works on your laptop and fails on a worker.

Of 61 node types, 9 pin a run to the main instance and 52 can run anywhere. The nine:

The Agent node is conditional. It pins the run only when a skill is attached, because skill code reads and writes stored files. Python tools, MCP tools and sub-workflow tools have no local file dependency and distribute freely.

The counterintuitive entry is what is not on the list. Our sandboxed code execution and our browser automation both distribute, even though both open a container.

Every instance runs the same image with its own container runtime, so a sandbox is not a reason to pin a run. Those two also happen to be the most CPU hungry things in the product, which means the nodes most worth moving off your busiest machine are exactly the ones a naive rule would have kept there.

One more rule matters more than it sounds: a single pinned node anywhere in the graph pins the entire run, and that check follows sub-workflows. If a workflow chooses its sub-workflow by an expression, the contents cannot be inspected before the run starts, so it pins too. Fail closed, at the cost of some throughput.

Percentages that are not percentages

Load is split by integer weights, and this is where operators get surprised. The weights are shares of the instances currently alive and enabled, not percentages of a hundred.

Set three machines to 41, 26 and 33. Turn the third one off. The remaining pool totals 67, so the main instance is now taking 41 divided by 67, which is 61 percent, not 41. Nobody changed a setting. The denominator changed.

Key principle: A capacity number that silently redefines itself when a machine goes offline is not a setting, it is a ratio. Read it as a share of whatever is alive, and size the busiest machine for the day the others are not.

Two related traps. A percentage is not a share of machine power, because it only covers work that goes through the queue, while serving the UI, streaming editor runs and handling uploads are all main's job and none of it is counted. And main's number is a ceiling rather than a floor, because runs that can only execute on main are charged against its quota. Setting main low is safe. Setting it high starves the workers.

What a cluster does to your audit trail

Now put box two and box three together, which is the whole point of this post.

Audit lines go to the stdout of whichever process emits them. If a platform emits audit lines from inside its execution engine, then in a three machine cluster those lines land on three different hosts, distributed by a weighting algorithm, and nothing anywhere reports that this happened. You will discover it during an incident review, which is the worst possible time.

Our answer is a rule in the repository rather than a feature: audit() may be called from API routers only, never from the executor or a node handler. Ingress points at the main instance, so a router call keeps the entire trail on one machine where a shipper can collect it. All 128 call sites obey it today and a reviewer's job is to keep it that way.

When an action genuinely originates during execution, it goes into the run's own history instead, which already carries the executing instance id and name on every row. That answers who did what and where from a single query, rather than from three log files nobody merged.

Notable fact: A cluster does not corrupt your audit trail. It splits it, silently, and every individual line remains perfectly correct.

The same shape applies to two other things a checklist will not ask. Every instance has to run the same version, the same database revision and the same encryption key, so we compare digests of both keys on every heartbeat and mark a mismatched instance so it receives no work at all.

That single check defines the upgrade order for free. Upgrade main first, every worker goes incompatible, load falls back to main, and each worker rejoins as it is upgraded. Slow, visible and reversible.

What that looks like day to day is a table with one row per machine. A status of Live with a fresh heartbeat, Offline after thirty seconds of silence, or Mismatch when the version, the database revision or a key digest differs from main's. Next to it, the round trip in milliseconds from that instance to the database, measured by the instance itself rather than inferred.

It is a plain table and it is the first thing I look at, because "Mismatch" is a machine that looks completely healthy, answers its heartbeat, and is deliberately being given no work at all.

And database connections scale with instances rather than users, which surprises people. Each instance runs several processes, each holding a pool plus listener connections. A three instance cluster on PostgreSQL's default max_connections of 100 runs out and the platform fails to reach its own database. Shrinking our pool defaults for cluster mode takes a two instance deployment from a 768 connection ceiling to 192.

We Ran the Checklist on Ourselves

Here is the standard checklist, answered honestly about our own platform. Five of the ten rows are worse than what a sales page would tell you: three partials and two flat nos.

The three partials and the two nos are the useful rows. If you are evaluating us, those are the ones to push on. If you are evaluating anyone else, notice how strange it feels to see them written down, and ask yourself why.

That table is what enterprise ready AI agents look like when the phrase is treated as a set of answers rather than a badge. Two of the rows would fail somebody's procurement gate outright, and knowing which two before the contract is signed is worth more than a page of yeses.

How These Numbers Were Produced, and How Young They Are

The counts are deliberately boring to reproduce. Router coverage is one search for the audit helper across the API directory, which returns 128 call sites in 15 files out of 51.

The placement figures are read from a single module holding one entry per node type, and a test fails the build if a registered node has no entry. That is why the total is exactly 61 rather than an estimate. Anyone with the repository can re-run both in under a minute.

Now the part that belongs in the same breath as the numbers. All three of these controls are days old. Audit logging landed on 25 August 2026, single sign-on on 26 August, and multi-instance execution on 29 August, against a repository whose first commit was 27 April.

So this is a 125 day old codebase reporting on three features with almost no production time behind them. The honest reading is that the design is defensible and the operational record does not exist yet.

When we counted router coverage five days earlier for the governance post it was 13 of 48. Two routers gained a line and three new ones appeared. The direction is right and the number is still 29 percent.

A Checklist You Can Run on Any Vendor

Six questions. None requires access to source code, all of them can be asked in a demo, and each one has an answer that is hard to fake.

1. Show me one audit line. Not the documentation. One line from a running system with the field names visible.
2. Which SSO do you mean? Workforce login for my team, or the credential the agent presents downstream. Ask for both.
3. What happens when the provider says the email is unverified? The only correct answer is that sign-in is refused.
4. What work cannot leave the first machine? Every horizontally scalable system has this list. Ask to see it.
5. Where does an audit line get written when I have three machines? This separates a design from a checkbox.
6. Who can turn off password login, and what stops them locking everyone out?

Then run the same six against the platform you already have. Counting your own audit coverage takes an afternoon, and the half of the result that stings is the half worth having. We found ours by writing this post, and if you are wiring approval gates or tracing into the same system, the exercise pays for itself immediately.

What This Post Is Not

It is not a vendor comparison, and I deliberately did not build the table where our column has more ticks than anyone else's. Every product named in the research for this piece solves a real problem for someone.

It is also not a compliance guide. SOC 2, ISO 27001 and GDPR appeared constantly in the pages I read, always as a proxy for capability, and they are not one. A certification describes how an organisation operates. It cannot tell you whether an AI agent audit log line is written on the machine you are collecting logs from.

And it is not a claim that enterprise AI agents are a solved category. The identity half is roughly twenty years old and mostly borrowed. The placement half is new, largely unwritten about, and where I expect the interesting failures to show up first.

And it is not finished. Our own scorecard has two nos and three partials on it. The reason to publish it anyway is that a checklist nobody can fail is not a control, and the only way I know to make one falsifiable is for somebody to go first.

If you want to see how the self hosted AI agent platform side of this works in practice, the platform operations documentation covers the SSO and multi-instance setup end to end, and our comparison of self-hosting options covers the licensing questions that usually come next. For the wider picture of where this sits, start with what AI workflow automation is.

Frequently Asked Questions

What security features should an enterprise AI agent platform have?

Three that buyers ask for and one they usually miss. Single sign-on against your own identity provider, an audit log of security relevant actions, and a way to scale past one machine. The one they miss is execution placement, which is the record of which machine actually ran a given workflow. Without it the first two degrade quietly, because an audit line written on whichever worker happened to pick up the job is a trail split across machines rather than a trail.

Why do AI agents need Single Sign-On (SSO)?

Two different questions get called this and they have different answers. The first is how the humans on your team sign in to the platform that builds and runs agents, which is ordinary workforce SSO through OIDC or SAML. The second is what credential the agent itself presents when it calls a downstream API, which is machine identity and is solved with per connection credentials, not with a login button. Most vendor writing answers the second and most buyers are asking the first.

Can self-hosted AI agent platforms meet enterprise security requirements?

Yes for the controls that are configuration, and it depends for the controls that are process. Single sign-on, audit logging, encrypted credentials and network isolation are all things software can ship. Certifications such as SOC 2 Type II describe an organisation and its operating procedures, so a self-hosted deployment inherits your own audit scope rather than a vendor's. The practical answer is that self-hosting moves the evidence burden to you and removes the third party from your data path.

How do AI agent platforms handle audit logging?

Usually as a structured line per security relevant action, carrying the action name, the actor, the outcome and the target. The design decisions that matter are what gets redacted and where the line is written. Our own helper strips any field whose key contains password, secret, token or api_key, truncates anything over 256 characters, and writes to stdout rather than a database table so your existing log shipper owns retention.

What is execution placement in a multi-instance deployment?

Execution placement is the rule that decides which machine in a cluster is allowed to run a given workflow. It matters because some work is tied to one machine, such as anything reading files from local disk or depending on a plugin installed there. In our own placement table 9 of 61 node types pin a run to the main instance and the other 52 can run anywhere, and a single pinned node anywhere in the graph pins the entire run.

Does SSO replace the need for an audit log?

No, and confusing the two is the most common gap in an enterprise AI agent platform. Single sign-on answers who was allowed in and stops there. An audit log answers what they did once inside. A platform can have flawless federated login and still be unable to tell you who deleted a credential last Tuesday, because those are separate subsystems that happen to appear next to each other on the same procurement checklist.