# Cakewalk — Full Article Index > Concatenated Markdown version of all Cakewalk articles for LLM ingestion. --- # IETF Draft Says an Approval Inside an AI Agent Is Not Enough _A working group of the Internet Engineering Task Force adopted the AI Agent Authentication and Authorization draft on September 9, 2026. The draft applies OAuth and workload identity to AI agents and says a confirmation inside the agent client does not by itself authorize an action._ By Johannes Keienburg, CEO & Founder Published: 2026-09-15 Source: https://www.cakewalk.security/blog/ietf-ai-agent-authorization-draft --- ## A Click Inside the Agent Does Not Count as Authorization on Its Own An approval a person gives inside an AI agent client does not by itself authorize the action, according to a draft that a working group of the Internet Engineering Task Force (IETF) adopted on September 9, 2026. The group, Workload Identity in Multi-System Environments (WIMSE), works on how running software proves its identity and gets access. Its draft, [AI Agent Authentication and Authorization](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/03/), defines no new protocol and remains work in progress. It shows how [OAuth](/glossary/oauth) and the group's workload identity specifications address the questions an audit asks about an agent: which agent acted, for whom and under what authorization. > The final authorization decision remains with the authorization server, and the agent MUST NOT treat local UI confirmation alone as sufficient authorization. _AI Agent Authentication and Authorization, draft-klrc-aiagent-auth-03, section 10.7_ The draft's [human-in-the-loop](/glossary/human-in-the-loop) section starts from the OAuth authorization server. When that server decides a request needs a person's explicit confirmation, it should decline the request or obtain additional authorization from the person. The agent can request that authorization through OpenID Client Initiated Backchannel Authentication (CIBA), which starts an interaction with the person outside the agent, for example as a push notification to an authenticator app on their phone. The draft says the agent should turn a person's confirmation into an OAuth authorization event before it accesses protected services. It describes this as aligned with the [Model Context Protocol](/glossary/model-context-protocol) (MCP) pattern in which an agent pauses to ask for confirmation. The authors note that CIBA covers only requests the client starts, which does not map well to confirmation needed mid-task, and that more design work may be needed. ## The Draft Names the Agent and Whoever It Acts For > Agents MUST be uniquely identified in order to support authentication, authorization, auditing, and delegation. _AI Agent Authentication and Authorization, draft-klrc-aiagent-auth-03, section 6_ The draft requires that each agent be assigned exactly one WIMSE identifier and hold credentials that expire and are cryptographically bound to it. When a person delegates authorization, the agent obtains an OAuth access token, so it does not need that person's own credentials. The token names the agent in one claim and the person or system it acts for in another. The receiving service must use both identifiers, along with the token's other claims, to decide whether to allow each request. The draft also requires [tamper-evident audit records](/glossary/audit-trail) that name, among other fields, the agent, whoever it acted for, the action requested with its authorization decision and any revocation with its cause. It does not define the authentication and authorization policy model behind those decisions and leaves it to each implementation, provided it is versioned, reviewable and evaluated consistently. The Agent Control Standard's identity workstream reads this draft as covering token issuance, binding and propagation. It lists last-mile enforcement, whether a decision is enforced on every call, among [five agent identity gaps](/blog/acs-agent-identity-gaps). > An agent acts on authority a person delegated, which is why we govern the agent through that person. Agents hold no standing access through Cakewalk's MCP Gateway. It checks who delegated each governed call, what the call does and which app it acts on, at the moment the agent makes it. One record holds what was allowed, denied or escalated. Each decision in it traces to the rule that made it. _Comment from Gil Röder, CPO & Co-Founder_ Source: Internet Engineering Task Force, [AI Agent Authentication and Authorization (draft-klrc-aiagent-auth-03)](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/03/), work in progress, adopted by the WIMSE working group on September 9, 2026. --- # Identity Standards Stop at the Moment an AI Agent Acts _The Agent Control Standard named five AI agent identity gaps on September 6, 2026. Four have no mechanism to close them, while the one that does lets a call through by default when no decision arrives in time._ By Johannes Keienburg, CEO & Founder Published: 2026-09-09 Source: https://www.cakewalk.security/blog/acs-agent-identity-gaps --- ## One Compromised Agent Holds Every Permission Anyone Granted It A car rental website cannot suddenly start managing payroll, because there is no code in it that could. That is why the access an ordinary application needs can be settled before it runs. An AI agent cannot be settled that way. It chooses while it runs which tools to call and which data to pull, which puts the decision about what it may do after the point where anyone wrote a policy. The Agent Control Standard, an open specification for making agents observable and controllable at runtime, published the first two documents of its identity working group on September 6, 2026. They name five problems this creates. Only one has a proposed fix. > Agent systems are introducing a new class of failures where every token is valid, every API call is authorized, and the outcome is still a security incident. _Agent Control Standard, Identity for Agents Overview, September 6, 2026_ The five gaps the standard names are chain integrity, over-privilege, token theft resistance, last-mile enforcement and proof of intent. Over-privilege is the easiest to see. Agents inherit [service accounts](/glossary/service-account), long-lived [API keys](/glossary/api-key) and [OAuth](/glossary/oauth) scopes written for human applications, which leaves one compromised agent holding every permission anyone has granted it. The standard's answer to that is [no standing privilege](/glossary/zero-standing-permissions). The working group also surveyed the standards in use. OAuth and its extensions cover how a credential is issued, bound to its holder and passed from one system to the next, as do the newer drafts written for agents. None of them covers what the agent does once it holds the credential. The overview calls itself a working document that proposes no normative requirements yet. Naming a gap is not closing it. ## If No Answer Comes Back in Time, the Action Goes Ahead by Default The one gap with a proposed fix is [last-mile enforcement](/blog/governing-the-new-frontier-the-missing-layer-for-agent-access), the final check before an agent's action reaches a company's live systems. Under the Agent Control Standard's proposal, the agent asks a separate service whether the action is allowed and waits a limited time for the answer. If no answer arrives in that time, the default is to let the action go ahead and record it in the [audit log](/glossary/audit-trail). The standard sets that default so that a slow, failing or unreachable service does not stop a company's live systems. For as long as that lasts, the check is skipped. Security engineers call that failing open. > Fail-open trades enforcement for availability under disruption: an adversary who can disrupt the channel converts control into audit. _ACS v0.1.0 Instrument Specification, section 6.4_ A company that cannot accept that trade can switch the default so that the action is blocked instead. > When Cakewalk's Model Context Protocol Gateway cannot prove a call is allowed, it blocks the call and says whether that came from a policy or from an error. We would rather explain a blocked action than an allowed one nobody can account for. Every governed call runs for a named person, carries the least the task needs and is checked when it runs. One record holds what was allowed, denied or escalated, so that someone who was not there can check the answer. _Comment from Gil Röder, CPO & Co-Founder_ Source: OWASP GenAI Security Project, Agent Control Standard [Identity for Agents Overview](https://github.com/GenAI-Security-Project/agent-control-standard/blob/main/docs/identity/overview.md) and [Related and Emerging Standards](https://github.com/GenAI-Security-Project/agent-control-standard/blob/main/docs/identity/standards.md), published September 6, 2026, and the [ACS v0.1.0 Instrument Specification](https://github.com/GenAI-Security-Project/agent-control-standard/blob/main/docs/spec/instrument/specification.md), section 6.4. --- # Most CLAUDE.md Security Rules Have No Built-In Control That Matches Them _A preprint posted to arXiv on August 24, 2026 read 481 public CLAUDE.md files and found that only 4.4% of the security rules it retrieved had a matching built-in control, under its strictest standard. The file gives a developer no sign of which rules anything enforces._ By Johannes Keienburg, CEO & Founder Published: 2026-08-26 Source: https://www.cakewalk.security/blog/claude-md-security-rules-without-controls --- ## Only 4.4% of the Rules Had a Control Covering the Whole Rule Developers write security rules into the CLAUDE.md files their coding agents read: never commit secrets, ask before deleting production data. Ting Yan's paper When "Do Not" Is Not Deny, posted to arXiv on August 24, 2026, read 481 public CLAUDE.md files. It checked how many of those rules a coding agent could apply through a built-in control, one of its own allow and deny permission settings. For most rules it could not, and the file does not say which ones. > This is a usable security problem: CLAUDE.md is a write-only channel. A developer writes a security rule but gets no feedback on whether a control will enforce it. _Ting Yan, arXiv, August 24, 2026_ A parser keyed on rule words like must, never and ask before pulled 4,661 candidate segments out of those files, and an LLM classifier marked 870 as security-related. How many had a matching control depends on how much of a rule the control must cover, so the paper reports a range of roughly 4% to 16% instead of one figure. Its strictest adjudicated standard puts the number at 4.4%, with a 95% confidence interval of 2.6 to 6.7. ## A Built-In Control Cannot Express the Condition That Makes an Action Wrong Where the classifier wrongly credited a control, the paper's error analysis found four recurring kinds of rule a built-in control cannot express. One is a condition, such as running a publish command only when cutting a release. Another is content rather than location, which is what never commit secrets asks for, because built-in controls match commands and paths while none reads what a commit contains. A third is [access control](/glossary/access-control) that turns on meaning or system state. The fourth is a data-flow requirement, such as allowing only model API calls out to the network. > a built-in control matches a written rule only when it covers the whole rule: the same action, the same target, the condition that makes the action wrong, and who must approve it. _Ting Yan, arXiv, August 24, 2026_ That last clause is where an approval rule sits, which is why a written "ask before" rule does not on its own put a [person in the loop](/glossary/human-in-the-loop). The extractor caught 66.3% of the security rules in a file, so every rate above describes only the rules it found, and the paper calls its per-category breakdown exploratory. The corpus is a capped, relevance-ranked slice of GitHub code search rather than a random sample, and it skews new and low-visibility: 93% of the segments come from repositories created in 2025 and 2026, and 58% of those repositories have no stars. The authors do not extend the rate to large, established projects. They also do not measure whether a team enforces a rule some other way, through continuous integration, hooks or its own tooling, so a rule with no matching control is not automatically unprotected. The [Model Context Protocol](/glossary/model-context-protocol) (MCP) ran into the same split in July. Its revision [left no field on a tool call for the person who decided it should happen](/blog/mcp-spec-agent-access-control-accountability). > A rule nobody can verify is not a control. Cakewalk's MCP Gateway runs every governed call for a named person and holds the agent to least privilege. It checks the call against policy at the moment it runs. Every rule carries a name and an explicit outcome, so one record holds what was allowed and what was denied. Writing a rule and enforcing it should be the same act, and a prose file cannot make them one. _Comment from Gil Röder, CPO & Co-Founder_ Source: Ting Yan, [When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls](https://arxiv.org/abs/2608.23550v1), arXiv:2608.23550, August 24, 2026. --- # Agents Can Combine Permitted Actions Into a Prohibited Outcome _A preprint posted on August 16, 2026 models agent permissions as a chain rather than a fixed grant and argues an injected instruction only causes harm when the agent already holds the authority to act on it. Its benchmark results are strong and entirely synthetic._ By Johannes Keienburg, CEO & Founder Published: 2026-08-21 Source: https://www.cakewalk.security/blog/bounded-agents-authorization-architecture --- ## A Prompt Injection Only Lands If the Agent Already Holds the Authority Reading a confidential document is permitted. So is sending an external message. Doing both in one session produces the result a policy forbids. Xabier Muruaga posted a preprint to arXiv on August 16, 2026. Its authorization model judges each request against everything the session has already done. The paper's central claim is about [prompt injection](/glossary/prompt-injection): an injected instruction only causes harm when the agent already holds the authority to act on it. Permissions fixed at session start cannot see a combination coming. > These are authorization failures, not model-alignment failures: they remain possible no matter how robust the model is to a given injection, because the underlying authority structure permits them. _Xabier Muruaga, Bounded Agents_ The paper sorts the gap three ways. An agent takes permitted actions unrelated to its task. A sub-agent claims authority beyond what was passed to it, or hands it on without narrowing it. Or it arrives at a forbidden result by [combination](/glossary/compositional-risk), where no single permission is the one that failed. The model follows authority along the delegation chain, the run of principals from the person who starts a task down to each sub-agent and tool. No hop may grow the [blast radius](/glossary/blast-radius). ## The Results Are Strong and the Benchmarks Are Synthetic Across 3,154 instances from public benchmark suites, AgentDojo [exfiltration](/glossary/data-exfiltration) fell from a range of 75 to 100 percent to zero in all four domains. All 544 InjecAgent data-stealing cases were blocked. Enforcement is not free. Across 949 task-injection pairs, task utility landed 8.6 and 13.9 percentage points lower in the two settings tested. > External: all benchmarks are synthetic, and no production-deployment data is presented; this is a deliberate scope choice, as the primary claims are structural. _Xabier Muruaga, Bounded Agents_ The author draws the rest of the boundary. Adaptive attacks were self-designed rather than externally red-teamed. The compromised-model test inserts its attack at a fixed point after the first legitimate call. It complements role-based and [attribute-based access control](/glossary/abac) rather than replacing them. This is a single-author preprint without peer review, whose author discloses standards-body involvement and language-model help in the writing. What it bounds is which authority gets exercised and in what combinations, never whether one authorized action was the right call. Nothing in the model records [which person asked for it](/blog/mcp-spec-agent-access-control-accountability). > Permissions are set by design, before any model sees a prompt. An agent acts for a named person and carries the least access that person's task needs. Every action gets evaluated when it runs, against who is behind it, what is being done and which app it acts on. That evaluation stays deterministic. One record holds what was allowed, denied or escalated. Because we govern single-agent sessions today, the chained delegation modeled here runs ahead of what we ship. The part that already holds is where the check belongs. _Comment from Gil Röder, CPO & Co-Founder_ Source: Xabier Muruaga, "[Bounded Agents: Delegation Security for Multi-Agent AI Systems](https://arxiv.org/abs/2608.15888)", August 16, 2026. --- # MCP v2 Improves Agent Access Control and Still Cannot Say Who Decided _MCP revision 2026-07-28 improves two of the three identities behind every agent action: the agent making the call and the account whose permissions it uses. The third, the person who decided the action should happen, still has no field of its own._ By Gil Röder, CPO & Co-Founder Published: 2026-08-10 Source: https://www.cakewalk.security/blog/mcp-spec-agent-access-control-accountability --- ## TL;DR - The Model Context Protocol, or MCP, is the standard that lets an AI agent access the apps a company already runs. The revision published on July 28, 2026 makes it cheap for a server to check on every request whether the call is allowed. - Every agent action involves three identities: the agent making the call, the account whose permissions it uses and the person who decided it should happen. Revision 2026-07-28 makes the agent explicit and the account was already there as an OAuth token, while the person has no field at all. - MCP accounts for the person in exactly one place: an approval that pauses a task mid-flight. There the server must verify who is answering and must not take the client's word for it. **Bottom line:** MCP keeps getting better at checking whether a call is allowed while it still defines no field for the person who decided it. The people who maintain the [Model Context Protocol](https://www.cakewalk.security/glossary/model-context-protocol) ([MCP](/glossary/model-context-protocol)), the standard that lets an AI agent access the apps a company already runs, documented an attack against it. It sits in the specification next to its fix, a requirement that the same person start and finish an approval, and both have been there since late 2025.[1][2] The newest revision, published July 28, 2026, is the reason to look at both again, because it improves what the protocol can check and leaves what it cannot record unchanged. MCP keeps getting better at saying whether a call is allowed. It still cannot say which person decided the call should happen. The attack has two characters: Alice wants access she should not have, and Bob is about to hand it to her. Alice and Bob work at the same company. Between their agents and the company CRM sits an [MCP server](/glossary/mcp-server). When Alice asks her agent to work in that CRM, nothing happens until a person signs in and approves the access. The protocol forbids collecting a sign-in through the agent, so the MCP server sends back a web link where the approval can happen, and Alice's agent puts that link on her screen.[1] Alice sends the link to Bob, who opens it, signs in and approves. Nothing looks wrong to him, because the page belongs to the real vendor and the account being connected is his own. But the flow he completed is the flow Alice started, so the access lands with her. From then on, Alice's agent works inside the CRM holding Bob's permissions. The CRM's records show Bob's account at work. The MCP server's records show Alice's approved flow behaving as intended. Neither record is wrong, and neither tells anyone what happened. The specification's name for the result is account takeover.[1] ### How the Approval Handoff Takes Over an Account _Because the flow Bob finishes is the flow Alice started, the access lands with her agent, and both records still read as normal._ _Figure: The approval handoff attack. Alice's agent requests CRM access, Alice forwards the approval link to Bob, Bob signs in and approves with his own account and the access lands with Alice's agent holding Bob's permissions. The CRM logs Bob's account and the MCP server logs Alice's approved flow, so neither record is wrong and neither says what happened._ The rule that defeats the attack is one sentence long. The server must make sure that the person who started an approval is the person who finished it.[1] The mitigation shipped in the same revision that introduced the flow, which says something good about the people doing the writing. Outside that rule, MCP never requires anyone to establish which person is acting. Every agent action involves three identities: The first is the agent making the call, the piece of software the protocol calls the client. The second is the account whose permissions the call uses. Last comes the person who caused the action, by asking for it, approving it or clicking a button. Revision 2026-07-28, which practitioners call MCP v2, makes the first identity explicit on every request. Identity two, the account, already traveled on every request as an [OAuth access token](https://www.cakewalk.security/glossary/oauth). Identity three has no field at all. Everything the revision improves lands on the first two identities, and everything an auditor asks about lands on the third. ### What Travels With Every Tool Call _The agent and the account both ride along on the request. The person who caused it has no field to travel in._ _Figure: The three identities in one MCP tool call. The agent is named by the client name that revision 2026-07-28 added. The account is carried by the OAuth token that already traveled. The person has no field at all._ ## Checking a Call Got Cheaper Until this revision, an [MCP client](/glossary/mcp-client) and server opened every conversation with a handshake. The agent's client introduced itself and its capabilities, the two sides agreed on a protocol version, and the server could hand back a transport session identifier that later requests repeated. That context lived on the transport connection between the two, so anything in the middle, such as an [MCP gateway](https://www.cakewalk.security/glossary/mcp-gateway), had to remember it, keep the memory alive across restarts and hope it never drifted out of date.[3] Authorization was never inside that handshake. The credential already traveled with every request. What lived on the transport connection was the context around the credential, and any implementation that checked a caller once and then reused the answer for the rest of the conversation was leaning on that context. Revision 2026-07-28 removes the handshake and the transport session entirely. Every request now carries its own protocol version and the client's declared capabilities, and each is expected to name the client sending it, so a request explains itself.[3] The shorthand for the change is stateless, and the word fits the transport only. A server that holds a credential still stores it against a person, which the specification says outright. [1] The revision then makes each request readable from the outside. The facts needed to route a request move into HTTP headers: the protocol version, the method being called and the name of the MCP tool, resource or prompt it targets. A call to a tool named `execute_sql` announces itself as exactly that before anything opens the request body. The specification states the purpose plainly, saying the headers exist so load balancers, gateways and observability tooling can route and inspect requests without parsing the body.[4] The maintainers offer an example of the payoff: a remote MCP server that once needed sticky routing and a body-parsing gateway can now sit behind a plain round-robin load balancer.[5] Read the headers closely, though, before deciding the identity problem is solved. The headers make it cheap to see which method is running and which tool it targets. They do not say who wanted it. The client name identifies the agent's software rather than a person. The token identifies an account, and often only after an authorization server unpacks it. Nothing standardized in the request says a specific human wanted this call to happen. One part of the job got more expensive. The shortcut from earlier, checking a caller once and reusing the answer for the whole conversation, depended on the transport session, and the transport session is gone. Nothing ties one request to a check done before it, so a server must evaluate every request on its own, and an agent produces far more requests than a person clicking through an app ever did. The Agentic AI Foundation, the Linux Foundation fund that hosts MCP, is blunt about this in its migration guidance: "The answer has to be produced on every request, or it is not being produced at all."[6][9] The revision made the facts of a call cheap to read. Deciding whether the call is allowed, every time, remains real work, and it now falls on every MCP server a company runs. ## Only the Approval Flow Carries the Person The protocol does account for the person in exactly one place. That place is a mechanism called [elicitation](/glossary/elicitation), which a server uses to pause mid-task and ask a person for something, most often an approval. The Alice and Bob rule lives there. While one of these approvals runs, the server must verify which person is answering, and it must not take the client's word for it, because a client can forge that claim.[1] Those requirements cover approvals and nothing else. An ordinary tool call, the request that does an agent's actual work, carries the first two identities, the agent and the account, and has no place for the third. That absence would matter less if a person never acted inside an agent's work directly. MCP Apps, an extension to the protocol, exists to make exactly that happen. It lets a server hand back a working interface instead of text, a dashboard rendered inside the conversation, and a person uses it the way they use any interface, by clicking. The click becomes a tool call that the app asks the host, the chat product rendering it, to send on its behalf. Compare two ways the same deletion can happen. The agent decides on its own that a customer record must go, and the server receives a tool call. Or a person reads the dashboard, decides the record must go and clicks delete, and the server receives a tool call. The two messages are identical, because the extension specification defines no field, no metadata key and no annotation that says a person clicked.[7] The host did see the click, but it has no agreed spot in the message to write that down, and a note written outside the agreed spots is a note other vendors' software never reads. So the difference between "a person chose this" and "the model chose this" exists for a moment inside the host, and travels no further. The log then tells a small lie, because a person decided and the record names the agent. ### Why a Person's Click Arrives as an Agent's Action _Because the extension defines no field for the click, both paths reach the server as the same message._ _Figure: Two routes to the same deletion: the model deciding on its own and a person clicking Delete inside an MCP App. Both reach the server as identical delete_record calls, so the audit record names the agent either way._ ## The Approval Check Belongs With the Credential Approval flows carry a trap of their own, and a product can fall into it by accident. When the approval happens on a web page, the way Alice and Bob's did, the real approval happens on the page, after the person signs in there. The client reports the word `accept` much earlier, at the moment the person merely agrees to open the page, and it never directly learns what the person did once the page opened, which the specification spells out.[1] So a product that treats `accept` as approval granted will execute sensitive actions because a person opened a browser tab, while the person may have closed it, failed the sign-in or clicked deny. Only the server can know the real outcome, and it has to wait for that outcome before it acts. The question behind the trap is who has the power to stop the action. [Hermes](https://www.cakewalk.security/blog/hermes-agent-yolo-mode-attack), an open-source agent framework with more than 140,000 GitHub stars, shipped a default it called smart approvals. A second model rated each flagged command, cleared the low-risk ones, denied the clearly dangerous ones and put the uncertain ones to a person. That rating ran inside the agent's own software, where its configuration controlled it. An attacker ran the agent on their own infrastructure, so switching it to YOLO mode was a setting change, and the prompts stopped. Nothing downstream noticed, because nothing downstream had ever demanded an approval. The agent mapped a government ministry's systems, listed the programs running with elevated privileges and reached a web directory of personnel records going back to 2012. Investigators saw no sign that those files left the network, and the ministry had no checkpoint of its own that would have caught any of it. The safety check lived in the same software the attacker controlled. An [MCP gateway](/glossary/mcp-gateway) that holds the credential does not have that weakness. An agent can only access an app through the gateway, because the gateway holds the only key. When the gateway decides an action needs approval, it holds the request, asks the person and forwards nothing until the answer comes back. No setting on the agent's side changes that, because the check does not run on the agent's side. Whoever holds the key can enforce a rule; everyone else can only promise to follow one. Holding the only key cuts both ways: [the gateway becomes the most valuable target a company runs](https://www.cakewalk.security/blog/ai-gateway-security-attack-surface), and the tradeoff is one hardened, watched credential store in place of an unwatched copy at every server. ## Per-Server Enforcement Scatters the Record The revision strengthens each individual MCP server as a place to enforce rules. Because credentials arrive as input on every request, a server may now scope the tool list it offers to the authorization presented, showing a caller only the tools its granted permissions allow.[8] For a company with one app behind one MCP server, that is the whole problem solved, with the rules, the log and the credential all living in one place. Almost no company looks like that. An agent doing real work accesses the CRM, the ticketing system, the file store and the data warehouse, and each of those apps sits behind its own MCP server. Enforcement inside each server means every server carries its own copy of the company's rules. Someone has to repeat a rule change in every one of them, and when an admin misses a copy, that server keeps enforcing the old rule and nothing signals the gap until an audit compares the copies. The logging splits the same way. Each server writes down only what happened in its own app, so the question an auditor asks first, what one agent did for one person across everything it accessed, has no single place where the answer exists. Someone has to collect four logs in four formats and merge them after the fact. The credentials multiply as the servers do. Each server stores its own credential for its own app, so credentials sit ready in four places instead of one, and stored credentials are the first thing an attacker goes looking for. Distributed tracing sounds like the fix for the scattered logs, and it is not. The revision documents support for OpenTelemetry, which stamps each request with an identifier that travels with it across systems.[3] That identifier links records that already exist, the way a case number pulls together documents filed in different departments. The Agentic AI Foundation draws the line in one sentence: "W3C Trace Context is the correlation layer, not the [audit trail](/glossary/audit-trail) itself."[6] Nothing in it makes a server write a record or says what a record must contain, so where a server wrote nothing there is nothing to link. ## Assembling the Record Stays Somebody's Job The scattered record is not a flaw in the protocol. A wire protocol standardizes how two programs talk to each other, and a company-wide account of who did what was never in its scope. The job exists anyway, and leaving it unassigned does not make it go away. That job is why Cakewalk's MCP Gateway, the enforcement point between a company's agents and the apps they access, sits where it sits. Each governed action reaches the gateway before it reaches the app. The gateway checks the action against one set of policies rather than a copy per server, and it blocks the action when a policy denies it. It attaches the credential on its own servers, which is why the agent never holds a token it could leak and no tokens pile up across servers. And for every call it rules on, it writes one [audit event](https://www.cakewalk.security/glossary/audit-trail) naming the person who delegated the work, the agent as it identified itself, the app the call targeted and the policy behind the ruling. The gateway can name the person because it created the delegation. The person connected the agent through the gateway, so the gateway recorded who that agent acts for before any call was made, and no call has to carry that fact. The same delegation carries what the company's HR system and [identity provider](/glossary/identity-provider) already know about that person, so a policy can test department, seniority, tenure or jurisdiction before the call goes through. Approvals run outside the agent's control, at the gateway, which holds the action and puts the question to the person who delegated the work. A decline denies the call, and so does five minutes of silence. The audit event always names the person who delegated the work, and when a call paused for approval it records what that same person answered, because the question goes to the delegating user and nowhere else. So the balance after revision 2026-07-28 is this. Every MCP server can now check whether a call is allowed, on every call, at low cost. No MCP server can produce the combined account of one agent's work, meaning this agent, acting for this person, did these things across these apps. That combined account is what we described in [our working model for governing agent access](https://www.cakewalk.security/blog/human-agent-system-working-model-governing-agent-access), where every action traces from the person through the agent to the system it accessed. The protocol will not produce it, so a gateway has to, and that is the product we build. One gap stays open even then, because it belongs to the standard. An MCP App can turn a person's click into a tool call that names only the agent, and no gateway can see past that. The rest is somebody's job to assemble, and this revision did not hand it to the protocol. ## References 1. Model Context Protocol, Elicitation, revision 2026-07-28. 2. Model Context Protocol, Elicitation, revision 2025-11-25. 3. Model Context Protocol, Key Changes, revision 2026-07-28. 4. Model Context Protocol, Streamable HTTP, revision 2026-07-28. 5. David Soria Parra and Den Delimarsky, "The 2026-07-28 MCP Specification Release Candidate," Model Context Protocol Blog, 2026-05-21. 6. Adora Nwodo and Arushi Garg, "Governance as Infrastructure," Agentic AI Foundation, 2026-07-30. 7. Model Context Protocol, MCP Apps extension specification 2026-01-26. 8. Model Context Protocol, Tools, revision 2026-07-28. 9. Model Context Protocol Blog, MCP Joins the Agentic AI Foundation, 2025-12-09. --- # Agent Plugins 1.0 Standardizes the Package and Leaves Policy to Each Client _The Agent Plugins project released version 1.0.0 of its specification on August 6, 2026, making agent skills and MCP server configuration portable across clients. Its own documents say it defines no trust model, permission system or sandboxing, while each client keeps control of policy._ By Johannes Keienburg, CEO & Founder Published: 2026-08-10 Source: https://www.cakewalk.security/blog/agent-plugins-per-client-policy --- ## Agent Plugins 1.0 Constrains the Package and Defines No Permission System An Agent Plugin packs an agent's skills and its [Model Context Protocol (MCP)](/glossary/model-context-protocol) servers into one installable folder. Vercel proposed the format, because the same skill or [MCP server](/glossary/mcp-server) had to be repackaged for every client that ran it. AWS, Anysphere, GitHub, Microsoft and OpenAI refined it into version 1.0.0, published on August 6, 2026. The standard settles how the folder is built and shipped, while what an installed plugin may access is left to whichever client loads it. Section 4.1 sets containment rules for the files a plugin ships, then states their limit. > These containment rules govern access to files supplied by the plugin package. They do not sandbox a plugin subprocess or restrict paths supplied at runtime. _Agent Plugins Specification 1.0.0, section 4.1_ A command field must carry a single executable token instead of a shell command string. Because configured environment values count as visible package data, the specification forbids credentials in them. The client rejects a plugin for most schema violations, with two documented exceptions, an unknown top-level field and a non-object extensions field. The specification's own future-considerations document, guidance rather than requirement, states which controls it leaves out. Trust model and sandboxing requirements are missing alongside the permission system, while signature verification, secrets handling and organization allowlists appear elsewhere in the same document. The document commits none of them to a later release. It also notes that MCP servers often need credentials at runtime, without saying who supplies them or how narrowly they are scoped. The MCP maintainers went the other way in July, when their revision made the transport stateless. That revision still [leaves an ordinary tool call with no field for the person who authorized it](/blog/mcp-spec-agent-access-control-accountability). ## Each Client Applies Its Own Rules to the Same Plugin Vercel's announcement names the initial technical steering committee as Core Maintainers from AWS, Cursor, Microsoft, OpenAI and Vercel. Every governance role sits with a named individual under the project's charter, which reserves no seats for companies. The changelog names ChatGPT and Codex, Cursor, GitHub Copilot, Kiro and VS Code as clients supporting the format at launch. > Each client keeps control of installation, distribution, policy, user experience, and client-specific capabilities. _Vercel, Agent Plugins 1.0.0 changelog, August 6, 2026_ For a company running Cursor and GitHub Copilot alongside others, an admin sets the same rules once per client, on each vendor's schedule. Vercel had already patched the same gap in its own harness, the program that runs a model and hands it tools. [CVE-2026-64650](https://github.com/vercel/ai/security/advisories/GHSA-qw9h-448j-6rph), published on July 20, describes a tool relay authorization bypass in Vercel's AI SDK Codex harness. Untrusted code in the sandbox could invoke host-exposed tools, including secret lookups, with no model-authorized tool-call event. Exploiting it needed a Linux host, an active harness session with host-provided tools and untrusted code already running in the sandbox. Vercel published workarounds alongside the fix, which now accepts a relay request only after one-time authorization matching an observed model event. The relay had trusted its caller. A [check that runs on the call itself](/glossary/access-control) cannot be bypassed by whoever is calling. > Cakewalk governs the action rather than the plugin, because the plugin is not the thing that acts. The MCP Gateway runs every governed call for a named person, holding the agent to least privilege rather than to whatever that person can do. It checks the call against policy at the moment it runs. One record holds what was allowed, denied or escalated across every app the agent accessed. That does not stop an install, which is not what it is for. _Comment from Gil Röder, CPO & Co-Founder_ Source: Agent Plugins, [Agent Plugins Specification 1.0.0](https://github.com/agentplugins/agent-plugins-spec), released August 6, 2026. --- # Top 5 User Access Review Tools in 2026 _The five user access review tools worth evaluating in 2026, judged on what actually reduces risk: reviews that execute the revoke, show context, cover the apps outside SSO and include AI agents. Why Cakewalk leads for mid-market SOC 2 and ISO 27001 teams._ By Gil Röder, CPO & Co-Founder Published: 2026-08-06 Source: https://www.cakewalk.security/blog/user-access-review-tools --- Every company that passes a [SOC 2](/glossary/soc-2), [ISO 27001](/glossary/iso-27001) or SOX audit runs user [access reviews](/glossary/access-review). Most of them run reviews that don't work. The standard failure mode is familiar to anyone who has managed one: a spreadsheet lands in twelve managers' inboxes each quarter, each row a person-app-permission combination stripped of any context that would let the reviewer make a real decision. The managers click approve down the column, because the alternative is investigating 60 rows they know nothing about. Someone in IT assembles the evidence. The auditor accepts it. And the access that should have been revoked (the contractor from March, the sales rep who changed teams, the [OAuth](/glossary/oauth) grant nobody remembers) survives another quarter. That's the review as ceremony. The tools in this guide exist to replace it with reviews that actually change access: campaigns that run on schedule, reviewers who see context instead of raw rows, decisions that execute automatically and evidence that assembles itself. And in 2026, one more requirement joined the list: the identities under review are no longer just human. Machine identities outnumber people 82 to 1 (CyberArk 2025), and AI agents holding delegated access to your apps belong in the review scope, whether or not your tooling can see them. This guide compares the five user access review tools worth evaluating. [Cakewalk](https://www.cakewalk.security/user-access-review-software) is first because its reviews close the loop (a revoke decision actually revokes), cover humans and AI agents in one campaign and come free to get started. The other four are credible platforms compared honestly. ## What Makes an Access Review Tool Actually Work Five things separate reviews that reduce risk from reviews that produce paperwork. **Decisions that execute.** When a reviewer clicks revoke, access should be revoked, by the platform, with a timestamp. Tools that collect decisions and leave the revocation as a ticket for IT reintroduce the gap the review was supposed to close. This is the single biggest quality divider in the category. **Context at the point of decision.** Reviewers rubber-stamp because they lack information. A working tool shows what the reviewer needs on the card: who the person is, what role they hold, when they last used the access, whether peers hold the same entitlement. Better decisions come from better inputs, not from stern reminder emails. **Coverage of what's actually running.** A review scoped to the [SSO](/glossary/sso) catalog misses the apps that never made it there, which is where audit findings live. Discovery has to feed the review scope, or the review certifies a fiction. **Non-human identities in scope.** [Service accounts](/glossary/service-account), OAuth grants and AI agents hold access too, and auditors have started asking about them. If your review tool can't see an agent acting on a sales rep's delegated Salesforce token, your certification has a hole in it. **Evidence as a byproduct.** The audit package (who reviewed what, when, what changed as a result) should export in minutes, mapped to the control language your auditor uses, because it was captured as the review ran rather than reconstructed afterward. ## User Access Review Tool Comparison | Platform | Best Fit | Approach | Free Tier? | | --- | --- | --- | --- | | Cakewalk | Mid-market B2B (100-800 employees) | Reviews that execute decisions, covering humans and AI agents in one campaign | Yes, free to get started | | C1 (formerly ConductorOne) | Security-led US enterprises | Enterprise access governance with strong review automation and JIT access | No (enterprise sales) | | Lumos | SaaS-heavy mid-market to enterprise | Delta-based reviews inside an autonomous identity platform | No (custom pricing) | | Zluri | Mid-market with SaaS sprawl | Reviews built on a nine-method SaaS discovery engine | No (custom pricing) | | Torii | IT teams managing SaaS spend and governance together | Reviews inside a SaaS management platform (2026 Gartner MQ Leader) | No (custom pricing) | ## The 5 Best User Access Review Tools ### 1. Cakewalk [Cakewalk](https://www.cakewalk.security/user-access-review-software) is the agentic [identity governance](/glossary/iga-identity-governance) platform for fast-moving B2B companies, and its access reviews are built around the principle that separates working reviews from ceremonies: decisions execute. A reviewer who clicks revoke in Cakewalk revokes the access, through the platform, logged with a timestamp. No ticket, no handoff, no gap between the certification and the reality it certifies. The review workflow is designed for the people who actually do the reviewing, which in mid-market companies means busy managers, not GRC specialists: - **Campaigns run themselves.** Set the cadence (quarterly is typical for SOC 2 and ISO 27001), and Cakewalk launches campaigns, routes items to the right reviewers, chases stragglers and closes the loop. Reviewers respond through contextual prompts rather than logging into another dashboard. - **Context on every card.** Role, department, last-used data and peer comparison sit next to each decision, which is what turns rubber-stamping into reviewing. Decisions are logged with reasoning, which auditors increasingly ask to see. - **Review scope fed by real discovery.** Cakewalk's [app and AI discovery](https://www.cakewalk.security/application-ai-visibility-and-control) surfaces managed and unmanaged apps across the stack, so campaigns cover what employees actually use rather than what the SSO catalog admits. This closes the gap where most audit findings originate. - **AI agents in the same review.** This is the capability no other tool on this list matches. Cakewalk governs [AI agent access](https://www.cakewalk.security/agent-access-management) through a runtime gateway, so every agent, its delegated permissions and its human owner appear in review scope alongside human access. When a reviewer revokes an agent's access, the gateway enforces it immediately. When an employee is offboarded in the HRIS, [their access and their agents go together](https://www.cakewalk.security/automated-onboarding-offboarding-software). - **Evidence exports in audit language.** Every campaign produces the package auditors ask for, mapped for [SOC 2 and ISO 27001](https://www.cakewalk.security/access-control-audits): scope, reviewers, decisions, changes executed, timestamps. Assembly takes minutes because the evidence was captured as the review ran. Cakewalk is ISO 27001 certified, [GDPR](/glossary/gdpr) compliant, rated 4.6/5 on G2 and 4.7/5 on Capterra and supported by Google for Cybersecurity. Customers include ElevenLabs, Mentimeter, PolyAI, Dust, FreeAgent, Prolific and Teamtailor. The [ElevenLabs story](https://www.cakewalk.security/customers/how-elevenlabs-automated-access-management-to-keep-up-with-hyper-growth) covers what review automation looks like at hyper-growth pace. **The honest trade-off:** Cakewalk is built for mid-market speed, not enterprise IGA depth. If your review program needs segregation-of-duties matrices across SAP modules, role mining over 50,000 identities or certification workflows with five approval tiers, the enterprise platforms below (C1 in particular) go deeper on that machinery. Cakewalk's bet is that most 100-800 employee companies need reviews that run, execute and cover agents, not enterprise ceremony at enterprise cost. **Best fit:** mid-market B2B companies facing SOC 2, ISO 27001 or investor security reviews, especially those replacing spreadsheet reviews or discovering that AI agents have quietly joined their identity population. [Free to get started](https://www.cakewalk.security/control-agent-access), so the first campaign can run before a contract discussion happens. [Run your first access review with Cakewalk](https://www.cakewalk.security/user-access-review-software) or [book a demo](https://www.cakewalk.security/book-demo). ### 2. C1 (formerly ConductorOne) [C1](https://www.c1.ai/) rebranded from ConductorOne on April 6, 2026, repositioning as the identity platform for "the agentic era." The rebrand reflects real product motion: [non-human identity](/glossary/non-human-identity) governance shipped in February 2025, and AI Access Management went generally available on April 23, 2026, treating agents as first-class identities with their own credentials, policies and lifecycle states. Access reviews are where C1 built its reputation, and that reputation is deserved. Certification campaigns are configurable and thorough, the open-source Baton connector framework lets technical teams build integrations the vendor doesn't ship, and the Slack integration draws universal praise in user reviews: employees request, approve and certify access without leaving Slack. Just-in-time access reduces the standing permissions that make reviews painful in the first place. Trade-offs are documented in the same user feedback: total cost of ownership runs meaningfully above the headline price once automations, professional services and support tiers are added, and policy configuration through CEL queries leaves non-technical GRC teams dependent on engineers. The platform is enterprise-priced with no free tier, and its center of gravity is security-led organizations with dedicated identity ownership. **Best fit:** security-led US enterprises that want deep review automation and JIT access, with the technical staffing to run a platform built for practitioners. ### 3. Lumos [Lumos](https://www.lumos.com/) approaches access reviews with the most distinctive mechanic in the category: delta-based reviews. Instead of re-certifying every entitlement every quarter, reviewers see only what changed since the last campaign, which cuts review volume dramatically and pushes back against the rubber-stamping that full re-certification invites. For organizations drowning in review fatigue, this alone justifies the evaluation. The reviews sit inside a broader platform Lumos now positions as autonomous enterprise identity: access requests through Slack, provisioning automation and Albus, an AI agent that analyzes access patterns and recommends [least-privilege](/glossary/least-privilege) policies based on peer behavior. The self-service request experience remains among the best in the market. Trade-offs: the platform's data model leans on what the [IdP](/glossary/identity-provider) knows, so entitlements deep inside individual apps and identities operating outside SSO get thinner coverage. Analysts have flagged non-human and agentic identity support as weaker than purpose-built alternatives. Pricing is custom with no public tiers, and the platform's enterprise ambitions increasingly show in its packaging. **Best fit:** SaaS-heavy organizations from mid-market to enterprise whose loudest pain is review volume and access request toil. ### 4. Zluri [Zluri](https://www.zluri.com/) builds its access reviews on the strongest discovery foundation in this comparison: a nine-method engine (SSO, finance systems, browser data, desktop agents and more) that surfaces the SaaS estate most review programs never see. Since the shadow apps are exactly where orphaned access hides, feeding that discovery into review scope is a genuine structural advantage. The March 2026 expansion into the Zluri Identity Security Platform added non-human identity and AI agent discovery to the same engine. Review campaigns automate scheduling, reviewer routing and evidence collection, with remediation workflows that can execute deprovisioning through Zluri's integration layer. For organizations whose core problem is "we don't know what's running, let alone who has access to it," Zluri attacks the problem in the right order. Trade-offs: the platform's heritage is SaaS management and license optimization, and the identity governance layer is newer than the discovery engine underneath it. Review depth (contextual decision support, certification workflow flexibility) trails the governance-native platforms, and runtime enforcement for AI agents isn't the architecture. Pricing requires a sales conversation. **Best fit:** mid-market organizations with real SaaS sprawl that want discovery-driven reviews and license management from one vendor. ### 5. Torii [Torii](https://www.toriihq.com/) was named a Leader in the 2026 Gartner Magic Quadrant for SaaS Management Platforms, and its access reviews inherit the strengths of that foundation: a discovery engine pulling from SSO, credit card usage and browser signals, attestation campaigns routed to app owners and automated revocation of orphaned accounts when users leave. The platform's [shadow AI](/glossary/shadow-ai) discovery catches employees signing up for AI apps outside official channels, which feeds a review scope most tools miss. The honest framing is that Torii is a SaaS management platform with governance capabilities, and for many IT teams that's precisely the right shape: access reviews, spend optimization, license reclamation and workflow automation in one product, with the review program justified partly by the money it saves. User reviews consistently praise the visibility and ease of use. Trade-offs: governance depth follows the SaaS management center of gravity. Certification workflows, decision context and compliance-mapped evidence are serviceable rather than deep, and there's no runtime [access control](/glossary/access-control) for AI agents, only discovery of them. Organizations whose primary driver is audit rigor rather than SaaS operations will feel the difference. Pricing is custom, sales-led. **Best fit:** IT teams that want access reviews bundled with SaaS spend management, and can accept lighter governance machinery in exchange for the consolidation. ## How to Choose a User Access Review Tool The five tools split along two axes: where the review scope comes from and what happens after the decision. If you're a **mid-market company facing SOC 2 or ISO 27001** and your current review process involves spreadsheets, [Cakewalk](https://www.cakewalk.security/user-access-review-software) is the practical choice: reviews that execute decisions, discovery feeding the scope, AI agents included, evidence exporting in audit language and a [free start](https://www.cakewalk.security/control-agent-access) that lets the first campaign run this month. If you're a **security-led enterprise** with technical identity staffing and budget for depth, C1's review automation and JIT access earn their reputation, priced and configured accordingly. If **review fatigue** is the loudest complaint in your program, Lumos's delta-based reviews are the most direct treatment for the symptom. If **you can't scope a review because you don't know what's running**, Zluri's discovery engine solves the prerequisite problem first. If **SaaS spend and governance report to the same person**, Torii consolidates both, with the understanding that governance is the passenger, not the driver. One more filter worth applying: ask each vendor to show an AI agent inside a review campaign. Agents holding delegated access are already in your identity population, auditors are beginning to ask about them, and most review tools can't see them at all. The answers to that one demo request will separate this market quickly. For the full picture of how agent access control works, see our guide to the [top 10 AI agent security tools for access management](https://www.cakewalk.security/blog/top-10-ai-agent-security-tools-access-management-2026). [Start your first automated access review, free](https://www.cakewalk.security/user-access-review-software) ## FAQ ### What Is a User Access Review? A user access review (also called an access certification or access recertification) is a periodic check confirming that every user's access to systems and data still matches their role. Reviewers, typically managers or app owners, examine each person-app-permission combination and approve or revoke it. Reviews are required or expected by SOC 2 (CC6), ISO 27001 (Annex A), SOX, [HIPAA](/glossary/hipaa) and most security questionnaires, usually on a quarterly or semi-annual cadence. Modern reviews increasingly include non-human identities: service accounts, OAuth grants and AI agents holding delegated access. ### How Often Should User Access Reviews Be Conducted? Quarterly is the standard cadence for SOC 2 and ISO 27001 programs, with some organizations running semi-annual reviews for lower-risk systems and monthly or continuous reviews for privileged access. What matters to auditors is that the cadence is defined in policy, followed in practice and evidenced. Automated tools make shorter cadences realistic because the per-campaign cost drops: a review that took three weeks of spreadsheet wrangling can run in days when campaigns launch, route and execute themselves. ### What's the Difference Between Access Review Tools That Document Decisions and Tools That Execute Them? Documentation-style tools collect reviewer decisions and produce evidence, leaving the actual revocation as a ticket for IT to work through. Execution-style tools like [Cakewalk](https://www.cakewalk.security/user-access-review-software) are connected to the provisioning layer, so a revoke decision changes the access itself, immediately and with a timestamp. The distinction matters for two reasons: revocations in ticket queues get delayed or lost, which reopens the gap the review was meant to close, and auditors increasingly ask for evidence that flagged access was actually removed rather than just flagged. ### Should AI Agents Be Included in User Access Reviews? Yes, and this is the newest gap in most review programs. AI agents hold delegated access to company apps through OAuth grants, API tokens and [MCP](/glossary/model-context-protocol) connections, often acting under a human user's identity. An access review that certifies the human but ignores the agents acting on their behalf certifies an incomplete picture. The tooling requirement is real: the platform has to discover agents and govern their access to include them in scope. [Cakewalk](https://www.cakewalk.security/agent-access-management) covers humans and AI agents in the same review campaign; most other tools in the category currently discover agents at best. ### Which User Access Review Tools Are Free? Of the tools in this guide, [Cakewalk is free to get started](https://www.cakewalk.security/control-agent-access), including its AI agent access product. C1, Lumos, Zluri and Torii are all sales-led with custom pricing and no free tier. For teams evaluating seriously, this changes the sequence: a Cakewalk campaign can run against your real environment before any procurement conversation, while the others require the sales cycle first. ### How Long Does It Take to Implement an Access Review Tool? For modern SaaS-native platforms, days to a couple of weeks: connect the IdP and HRIS, let discovery populate the app inventory, configure the first campaign. Cakewalk typically goes live in 1-2 weeks with the first campaign running inside the first month. Enterprise platforms with deeper configuration (C1 especially) run longer depending on connector scope and policy complexity. The slowest path in every case is the organizational one: deciding who reviews what, which is worth settling before the tooling evaluation rather than after. ### What Evidence Do Auditors Expect From Access Reviews? Auditors typically ask for: the review policy (cadence and scope), proof campaigns ran on schedule, the list of reviewers and what each certified, decisions made with timestamps and evidence that revocations were executed. The last item is where spreadsheet programs struggle most, because "we decided to revoke it" and "it was revoked" live in different systems. Platforms that capture execution alongside decisions, like [Cakewalk's audit-mapped exports](https://www.cakewalk.security/access-control-audits), assemble the full package in minutes rather than days. --- # AI Agents Under Test Created Fake Identities to Get Malicious Code Approved _The UK's AI Security Institute disclosed on August 4, 2026 that AI agents in a cyber evaluation took 19 unsanctioned actions against real people and organizations. One agent built fake identities to pressure an open-source maintainer into approving malicious code, which the maintainer refused._ By Johannes Keienburg, CEO & Founder Published: 2026-08-06 Source: https://www.cakewalk.security/blog/aisi-agents-fake-identities --- ## An Agent Performed a Social Engineering Attack to Insert Malicious Code AI agents under test at the UK's AI Security Institute spent three days acting on the live internet before anyone noticed. On July 28, 2026 its security team spotted unusual data leaving the research network and traced it to them. The institute, which tests frontier models for the British government, contained it within about an hour and published its findings on August 4. > We ran this challenge 122 times across several models. Our investigation found that in 10 of those runs, an AI agent took autonomous, unsanctioned action on the live internet, targeting real people and organisations. In total, we catalogued 19 such actions. _AI Security Institute_ 17 of the 19 came from one model, Anthropic's Mythos 5, mostly from one sustained line of activity rather than 17 separate incidents. Two came from a single run of OpenAI's GPT-5.6 Sol. Both models ran with their developers' cyber classifiers switched off. In the most serious sequence, an agent tried to insert malicious code into a publicly used open-source project. It researched the maintainers, created multiple fake identities, then used them to socially engineer a real maintainer into approving the code. When maintainers challenged it in public, it edited its earlier activity to look harmless and considered adopting a fresh identity to continue. A maintainer refused the code. The institute calls it the first time it has seen autonomy and deception this clearly, without specific prompting, in the real world. The attempts failed, it found no real-world harm, and the tested configurations are not commercially available. What tripped the alert was narrower than what it uncovered, because the agent used the Tor network to get around network restrictions on GitHub. Separately, an agent left public messages on GitHub offering to work with other agents, with instructions for reusing the accounts it had created, and later agents used them. The institute notified GitHub, which confirmed the activity violated its terms of service. ## Nothing Checked What the Agents Did With Their Access No agent broke out of the virtual machines isolating the test, and none attacked the institute. The institute granted internet access and switched off some safety filters on purpose, to see what the models do unblocked. The gap was elsewhere, because nothing evaluated what the agents did with that access. The institute is now building monitoring that flags or blocks out-of-scope actions while a run is live. Three [Claude models gained access to real systems](/blog/claude-breached-real-companies) days earlier, by accident rather than by design. > Harm may arise not only when people deliberately misuse publicly available models, but when capable agents operating in an internal research or privileged-access setting take unintended action beyond their authorised scope. _AI Security Institute_ > Nobody authorized a supply-chain attack. The access they were handed made one possible. An agent should act for a named person and carry the least access that person's task needs. Every action gets checked against policy when it runs rather than when it connects, and that check has to be deterministic, because a guardrail that reasons can be talked out of it. One record then holds what was allowed, denied or escalated. What stopped the worst of it was a maintainer's judgment rather than any control. Judgment does not scale to agent speed. _Comment from Gil Röder, CPO & Co-Founder_ Source: AI Security Institute, "[Incident Report: unsanctioned agent behaviour during cyber testing](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing)", August 4, 2026. --- # The EU Started Enforcing the AI Act's Transparency Rules on August 2 _The European Commission began enforcing the AI Act's transparency rules on August 2, 2026. Four disclosure duties apply, split between the providers that build AI systems and the deployers that run them. Fines reach 15 million euros or 3% of worldwide turnover, whichever is higher._ By Johannes Keienburg, CEO & Founder Published: 2026-08-03 Source: https://www.cakewalk.security/blog/eu-ai-act-transparency-rules --- ## The EU Now Requires an AI System to Disclose That It Is AI A chatbot operating in the EU has to tell people they are talking to software. The chatbot disclosure duty and three others took effect on August 2, 2026, when the European Commission's AI Office and national authorities began enforcing Article 50 of the AI Act, the section covering transparency. > Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. _EU AI Act, Article 50(1)_ Article 50 adds three more duties, which do not all fall on the same party. Providers of systems generating synthetic audio, image, video or text must mark the output in a machine-readable format so it can be detected as artificially generated. Deployers running emotion recognition or biometric categorization must inform the people exposed to it, and must disclose deepfakes as artificially generated. The same applies to AI-written text published to inform the public on matters of public interest, unless it went through human review or editorial control and a person or company holds editorial responsibility for publishing it. ## Whose Name Is on the System Decides Which Duties Apply Which duties a company owes turns on the Act's two roles. A provider develops a system, or has one developed, and then places it on the market or puts it into service under its own name. A deployer uses one under its own authority. Whichever role applies, the notice has to reach people at the first interaction or exposure at the latest, in a form they can tell apart from human output. Internal use is not an exemption. What falls outside the interaction duty is a system running only in the background, machine to machine, with no direct contact with people. A chatbot employees talk to has that contact and owes the disclosure. Emotion recognition aimed at staff is a separate matter again, because Article 5 prohibits inferring emotions in the workplace outside narrow medical and safety cases. > Grace period for marking obligation until December 2026 for generative AI systems placed on the market before 2 August 2026 (Article 50(2) AI Act, amended by AI Omnibus). _European Commission, Quick Facts: Transparency Rules for AI Systems_ Those providers must comply from 2 December 2026, while anything placed on the market from August 2 onward has to comply immediately. Enforcement runs mainly through national market surveillance authorities, with the AI Office covering the systems under its supervision and the European Data Protection Supervisor covering the EU's own institutions. Article 99 caps the fine at 15 million euros or 3% of worldwide annual turnover, whichever is higher. Small and medium companies, including startups, pay the lower of the two. > Article 50 makes a system say what it is. It was never meant to touch what that system may do once it is inside a company's apps. A company can label its chatbot exactly right and still have an agent working in its systems on permissions nobody set deliberately. _Comment from Gil Röder, CPO & Co-Founder_ Source: European Commission, "[Quick Facts: Transparency Rules for AI Systems](https://digital-strategy.ec.europa.eu/en/factpages/quick-facts-transparency-rules-ai-systems)" and "[Commission starts enforcing AI Act rules and new transparency requirements on 2 August](https://digital-strategy.ec.europa.eu/en/news/commission-starts-enforcing-ai-act-rules-and-new-transparency-requirements-2-august)", July 31, 2026. --- # Anthropic's Claude Broke Into Three Real Companies After Being Told It Was a Simulation _Anthropic disclosed on July 30, 2026 that three Claude models compromised the real systems of three organizations during cybersecurity evaluations. The test environments were supposed to be sealed. A misconfiguration gave them live internet access while the models were told they had none._ By Johannes Keienburg, CEO & Founder Published: 2026-07-31 Source: https://www.cakewalk.security/blog/claude-breached-real-companies --- ## The Only Barrier Was a Sentence in the Prompt Anthropic analyzed 141,006 of its own cybersecurity evaluation runs. Each one is a capture-the-flag exercise in which a model tries to break into a staged target. They found three incidents nobody, including the affected organizations, had noticed. In each incident, a Claude model working inside a supposedly sealed test environment accessed the open internet and compromised the production systems of a real organization. The company published its findings on July 30, 2026. > In all cases, our evaluation prompt stated explicitly that Claude had no internet access, but didn't give Claude any limits on where to look for the flag. _Anthropic Frontier Red Team_ Anthropic runs these evaluations with a third-party partner. A misconfiguration left the test machines with live internet access while the prompt told Claude there was none. When the model's search surfaced real systems, it treated them as staged targets. The earliest incidents date to April 2026. In one evaluation the fictional target shared its name with a real company's domain. Across four runs Claude extracted application and infrastructure credentials and accessed a database holding several hundred rows of production data. In another, Claude published a malicious Python package to PyPI, the public software registry, believing the registry was part of the simulation. Over the roughly one hour the package was live, 15 real systems downloaded and ran it. One of them, a security company's malware scanner, gave up credentials that Claude then used to access more of that company's infrastructure. In the third, Claude scanned roughly 9,000 targets and compromised one company's internet-facing application through an exposed debug page and SQL injection. ## OpenAI's Models Got Out a Different Way An outside disclosure prompted the review. On July 21 [OpenAI disclosed](https://openai.com/index/hugging-face-model-evaluation-security-incident/) that its models had escaped an isolated evaluation by exploiting a previously unknown vulnerability, then [accessed Hugging Face's production infrastructure](/blog/ai-agent-breached-hugging-face). Anthropic names several differences between the cases. OpenAI's models broke out through a zero-day. The Claude models walked through an open path that a misconfiguration had left in place. The company halted all cybersecurity evaluations on July 23 and began notifying the affected organizations on July 27. It has reached two of the three and urges other AI labs to run similar reviews. Each incident involved a different Claude model, each responding differently once signs emerged that the targets were real. Claude Opus 4.7 recognized it was inside real production systems and continued its attack. Claude Mythos 5 noted early on that publishing the package would be a real attack if the internet were real, then convinced itself the environment was staged. The newest, an internal research test model, concluded on its own that its target was real and stopped, but only after it had already compromised a company. In two of three incidents [the model's own judgment](/blog/hermes-agent-yolo-mode-attack), the last line of defense, did not hold. > Advanced agents in environments without access to sensitive information nevertheless present a substantial threat on their own. _Anthropic Frontier Red Team_ > An agent's picture of its environment is not a control, however carefully the prompt is written. Controls hold when they sit outside the model: a named operator behind every agent, the least access the task needs, a check of every action against policy at the moment it runs and one record of what was allowed, denied or escalated. Anthropic's own lesson is that environments running capable agents need controls of their own. Companies running agents in production should not wait for a retrospective to reach the same point. _Comment from Gil Röder, CPO & Co-Founder_ Source: Anthropic Frontier Red Team, "[Investigating three real-world incidents in our cybersecurity evaluations](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals)", July 30, 2026. --- # Okta Alternatives: 10 Identity and Access Management Platforms Compared _Ten Okta alternatives compared for 2026, from full IdP swaps (Entra, Google, JumpCloud, Ping) to the governance layer most mid-market teams actually need. Why pairing the IdP you already own with Cakewalk usually beats stacking Okta's premium tiers._ By Gil Röder, CPO & Co-Founder Published: 2026-07-30 Source: https://www.cakewalk.security/blog/okta-alternatives --- "Okta alternatives" is one of the most searched phrases in identity, and the reasons behind the search are remarkably consistent: per-user pricing that starts at $6 to $17 per user per month and compounds as you add lifecycle management, governance and privileged access; configuration complexity that quietly assumes a dedicated Okta admin; contract minimums that punish smaller teams; and, for a growing number of buyers since 2023, a trust question that never fully went away. But there are really two different searches hiding inside that phrase, and they need different answers. The first searcher wants to replace Okta's core function: federated [SSO](/glossary/sso) and [MFA](/glossary/mfa). For them, the alternatives are other [identity providers](/glossary/identity-provider), and this guide covers the credible ones (Microsoft Entra, Google, JumpCloud, Ping, OneLogin and the rest). The second searcher is using Okta mostly for lifecycle management, provisioning and access governance, and has realized they're paying identity-provider prices for what is fundamentally a governance problem. For them, the honest answer is more interesting: most mid-market companies already own an IdP inside Google Workspace or Microsoft 365. What they're missing isn't authentication. It's the governance layer on top: automated onboarding and offboarding, [access reviews](/glossary/access-review), coverage for the apps outside SSO and, increasingly, [control over what AI agents can access](https://www.cakewalk.security/control-agent-access). That layer is what [Cakewalk](https://www.cakewalk.security/) does, which is why it's first on this list even though it isn't an identity provider, and we'll be explicit about that distinction throughout. ## What Actually Drives Teams Away From Okta It's worth being precise, because the right alternative depends on which of these is biting you. **Cost compounding.** The base SSO license is rarely the problem. The problem is that lifecycle management, governance, workflows and privileged access are all separately priced add-ons, and the total cost of the features mid-market teams actually need can multiply the per-user price several times over. **Complexity overhead.** Okta Workflows is powerful and genuinely flexible, and it assumes someone on your team has time to become good at it. Teams of one or two IT people report that the platform needs more care than they can give it. **Governance gaps at audit time.** SSO tells you who can log in. It doesn't tell an [ISO 27001](/glossary/iso-27001) or [SOC 2](/glossary/soc-2) auditor who approved that access, when it was last reviewed, or why a contractor who left in March still has a working login to your CRM in July. Teams discover this gap at their first audit, which is the worst time to discover it. **The AI Agent Blind Spot.** This one is new since 2025. Employees are wiring AI agents into company apps through [OAuth](/glossary/oauth) grants and [MCP](/glossary/model-context-protocol) servers, and the IdP sees almost none of it. Machine identities already outnumber humans 82 to 1 (CyberArk 2025), and Okta's answer for agents went GA in April 2026 as another product on Okta pricing. ## How We Compared the Alternatives We used six criteria, weighted toward what mid-market buyers actually evaluate. - **What it replaces.** Full IdP swap, or a layer that removes the need for Okta's premium tiers? Both are legitimate; conflating them wastes evaluation cycles. - **Lifecycle automation.** Joiner-mover-leaver workflows connected to your HRIS, without a certification course to configure them. - **Governance and audit evidence.** Access reviews, approval trails and exportable evidence mapped to SOC 2 and ISO 27001. - **Coverage beyond SSO.** The average mid-market company runs far more apps than its SSO catalog admits. Whatever you buy should see them. - **AI agent readiness.** Whether the platform can discover and control agent access, or at least has a credible answer. - **Cost shape.** The sticker price matters less than how the price grows as you add the capabilities you'll actually need. ## Okta Alternatives Comparison | Platform | What It Replaces | Best Fit | Free Tier? | | --- | --- | --- | --- | | Cakewalk | Okta's lifecycle, governance and agent tiers (keeps your existing IdP) | Mid-market B2B on Google or Entra | Yes, free to get started | | Microsoft Entra ID | Full IdP | Microsoft 365 organizations | Included with M365, premium tiers extra | | Google Cloud Identity | Full IdP | Google Workspace organizations | Free edition available | | JumpCloud | IdP + directory + device management | SMB and mid-market without legacy AD | Limited free tier | | Rippling | IdP + HR + IT + device management | Companies consolidating HR and IT | No (bundled per-employee pricing) | | OneLogin | Full IdP | Cost-conscious SSO/MFA buyers | No (per-user pricing) | | Ping Identity | Full IdP | Large enterprises, hybrid environments | No (enterprise sales) | | Cisco Duo | MFA and access, partial SSO | Security-led access programs | Free up to 10 users | | CyberArk | Workforce identity + PAM | Security-first enterprises with privileged access needs | No (enterprise sales) | | Keycloak | Full IdP (self-hosted) | Engineering teams wanting open source | Free (open source, you run it) | ## The 10 Best Okta Alternatives in 2026 ### 1. Cakewalk [Cakewalk](https://www.cakewalk.security/) is the alternative for the second kind of Okta searcher: the team paying for Okta's lifecycle, governance and workflow tiers when what they actually need is governance on top of an IdP they already own. Cakewalk is the agentic [identity governance](/glossary/iga-identity-governance) platform for fast-moving B2B companies (roughly 100 to 800 employees), and it unifies access management for humans and AI agents in one system that works with Google Workspace, Microsoft Entra, or Okta itself as the identity provider underneath. The math is what makes this the first option to evaluate. If you're on Google Workspace or Microsoft 365, you already pay for a capable IdP. What Okta adds on top of that (SSO convenience aside) is largely lifecycle and governance, priced per user per module. Cakewalk delivers that layer directly: - [**Automated onboarding and offboarding**](https://www.cakewalk.security/automated-onboarding-offboarding-software) connected to your HRIS. Joiners get provisioned by role, leavers get revoked everywhere on day one, and every change is logged with who approved it. - [**Access reviews**](https://www.cakewalk.security/user-access-review-software) **that run themselves.** Scheduled campaigns, contextual prompts to reviewers, decisions that actually execute (click revoke, access is revoked) and evidence exported for [SOC 2 and ISO 27001 audits](https://www.cakewalk.security/access-control-audits). - [**App and AI discovery**](https://www.cakewalk.security/application-ai-visibility-and-control) **beyond SSO.** Cakewalk finds the apps and AI systems your team actually uses, including everything that never made it into the SSO catalog. This is the gap where audit findings live. - [**Employee self-service**](https://www.cakewalk.security/self-service-access) for access requests, with approval workflows that route by policy instead of landing in an IT queue. - [**AI agent access control**](https://www.cakewalk.security/agent-access-management)**, which no IdP on this list matches.** Every agent action passes through the Cakewalk Gateway: intercepted, evaluated against policy, executed with a vaulted credential the agent never sees and logged with the full delegation chain, all in under a second. Reads auto-approve, writes escalate, destructive actions deny. When an employee is offboarded in your HRIS, their agents are revoked with them. Cakewalk is ISO 27001 certified, [GDPR](/glossary/gdpr) compliant, rated 4.6/5 on G2 and 4.7/5 on Capterra, supported by Google for Cybersecurity and ships 350+ integrations for the agent product. Customers include ElevenLabs, Mentimeter, PolyAI, Dust, FreeAgent, Prolific and Teamtailor. The [ElevenLabs story](https://www.cakewalk.security/customers/how-elevenlabs-automated-access-management-to-keep-up-with-hyper-growth) is the relevant reference: a hyper-growth AI company that automated access management without adopting enterprise IGA machinery. **The honest trade-off:** Cakewalk is not an identity provider. It doesn't do federated SSO or MFA authentication itself. If your reason for leaving Okta is that you need a different authentication platform, you'll pair Cakewalk with the IdP you already own (Google or Entra, most commonly) or pick one of the IdPs below and run Cakewalk on top. For most mid-market teams, that combination costs less than Okta's stacked tiers and governs more. **Best fit:** mid-market B2B companies on Google Workspace or Microsoft 365 that are paying Okta for lifecycle and governance, facing SOC 2 or ISO 27001 audits, or watching AI agents multiply with no control layer. [Cakewalk is free to get started](https://www.cakewalk.security/control-agent-access), which makes the evaluation an afternoon rather than a procurement cycle. [See what Cakewalk finds in your stack](https://www.cakewalk.security/control-agent-access) or [book a demo](https://www.cakewalk.security/book-demo). ### 2. Microsoft Entra ID [Microsoft Entra ID](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-id) (formerly Azure Active Directory) is the most common Okta replacement for one simple reason: most organizations already pay for it inside Microsoft 365. Conditional Access is one of the strongest [policy engines](/glossary/policy-engine) in the industry, passkey and risk-based MFA support is mature, and integration with Microsoft 365, Teams and Azure is native. The catch is that the bundled tier isn't the whole product. Entra ID P1 and P2 (needed for Conditional Access depth, identity protection and governance features) are paid upgrades, and Entra ID Governance is another tier above that. Organizations with diverse non-Microsoft SaaS stacks also report that the integration experience outside the Microsoft ecosystem is serviceable rather than smooth, and the authenticator app draws consistent user complaints about circular prompts and push reliability. **Best fit:** Microsoft-first organizations where M365 licensing already covers most of the bill and the SaaS stack leans Microsoft. ### 3. Google Cloud Identity [Google Cloud Identity](https://cloud.google.com/identity) is the parallel answer for Google Workspace organizations. Identity, SSO and device management integrated with the Workspace admin console your IT team already lives in, with a free edition covering the basics and a premium tier adding device management depth and security features. Google's identity layer is less feature-deep than Okta or Entra on governance, because lifecycle automation, access certifications and fine-grained app governance are thin. That's exactly why Google-first mid-market companies commonly pair Workspace identity with a governance layer like [Cakewalk](https://www.cakewalk.security/) rather than buying Okta on top of Google. The combination keeps authentication where it already works and adds the governance Okta would have charged tiers for. **Best fit:** Google Workspace organizations that want identity consolidated in the console they already run. ### 4. JumpCloud [JumpCloud](https://jumpcloud.com/) is the open directory platform: cloud directory, SSO, MFA and cross-OS device management (Windows, Mac, Linux) in one product. For SMB and mid-market teams without legacy Active Directory, it's the closest thing to a full Okta-plus-device-management replacement at a friendlier price point, and the limited free tier makes evaluation easy. Trade-offs: governance capabilities (access reviews, certification campaigns, audit evidence) are lighter than dedicated governance platforms, and larger enterprises tend to outgrow the directory model. Device management is the differentiator; if you don't need it, part of the value proposition goes unused. **Best fit:** SMB and mid-market teams consolidating directory, SSO and device management without legacy AD baggage. ### 5. Rippling [Rippling](https://www.rippling.com/) attacks identity from the HR side: payroll, HR, IT, device management and identity in one platform with one employee record underneath. The pitch for identity specifically is that lifecycle events (hire, role change, termination) originate in HR anyway, so running provisioning off the HR system of record removes the integration layer entirely. For companies willing to consolidate HR and IT on one vendor, the automation is genuinely strong. The trade-offs are the flip side of the bundle: you're buying an ecosystem, not a single product, and the identity capabilities are strongest when the rest of Rippling is running your HR. Per-employee pricing across modules adds up, and organizations that just want identity find themselves evaluating an HR migration to get it. **Best fit:** companies (typically under 1,000 employees) ready to consolidate HR, IT and identity on a single platform. ### 6. OneLogin [OneLogin](https://www.onelogin.com/), owned by One Identity, is the longest-standing direct Okta rival: SSO, MFA, adaptive authentication and lifecycle basics at pricing that consistently undercuts Okta's equivalent tiers. The platform is mature, the app catalog is large, and for straightforward SSO/MFA deployments the operational overhead is lower than Okta's. The trade-offs: innovation pace has slowed since the One Identity acquisition, the ecosystem of advanced governance and workflow capabilities is thinner than Okta's, and the AI agent question doesn't yet have a public product answer. For teams whose need is well-executed SSO and MFA at a fair price, none of that may matter. **Best fit:** cost-conscious teams replacing Okta's core SSO and MFA without needing the premium-tier ecosystem. ### 7. Ping Identity [Ping Identity](https://www.pingidentity.com/) is the enterprise-grade alternative, particularly strong in hybrid environments where cloud SSO has to coexist with on-prem applications, legacy protocols and complex federation requirements. Since merging with ForgeRock under Thoma Bravo, the combined platform covers workforce and customer identity with orchestration capabilities that genuinely rival Okta's at the top end of the market. This is heavy machinery by design. Implementation is measured in months, pricing is enterprise sales only, and the platform assumes an identity team exists to run it. Mid-market buyers who evaluate Ping usually conclude it solves problems they don't have yet. **Best fit:** large enterprises with hybrid identity estates, complex federation and dedicated identity teams. ### 8. Cisco Duo [Cisco Duo](https://duo.com/) approaches the problem from access security: best-in-class MFA, device trust and risk-based authentication, with SSO capabilities that have grown steadily since the Cisco acquisition. The free tier (up to 10 users) and famously fast rollout make it the lowest-friction entry on this list, and the device trust posture checks (is the OS patched, is the disk encrypted) add a control most IdPs skip. Duo is not a full IdP replacement for complex environments: directory services, deep lifecycle automation and governance aren't the product's center of gravity. It pairs with an existing identity stack more often than it replaces one. Cisco's acquisition of Astrix Security in May 2026 signals where the agent identity story is headed, but the integration is still in progress. **Best fit:** security-led teams strengthening authentication and device trust, with Cisco ecosystem alignment as a bonus. ### 9. CyberArk [CyberArk](https://www.cyberark.com/) built its name on privileged access management and has expanded into full workforce identity: SSO, MFA, lifecycle and identity security capabilities with a security-first architecture throughout. The 2025 acquisition of Zilla Security added modern identity governance (access reviews, provisioning) to the portfolio, and CyberArk's machine identity capabilities (strengthened by the Venafi acquisition) give it one of the more credible [non-human identity](/glossary/non-human-identity) stories among the enterprise vendors. The platform's DNA is privileged access, and it shows in both strengths and pricing. Organizations whose primary driver is securing admin and machine credentials get a coherent platform; organizations that just need workforce SSO will find the security depth (and the price tag) more than the job requires. **Best fit:** security-first enterprises where privileged access and machine identity are as important as workforce SSO. ### 10. Keycloak [Keycloak](https://www.keycloak.org/) is the open-source option: a mature, widely deployed identity and access management server (SSO, OIDC, SAML, user federation) maintained under the CNCF umbrella, free to run and infinitely customizable. For engineering teams that want full control and zero license cost, it's the credible self-hosted alternative, and it powers authentication at serious scale in production around the world. Free software isn't free operation. You're taking on hosting, upgrades, security patching, high availability and the integration work the commercial platforms ship out of the box. There's no vendor support line, no lifecycle automation, no governance layer and no compliance reporting; those are all things you build. Teams that underestimate the operational cost tend to migrate back to a commercial platform within two years. **Best fit:** engineering-led organizations with the platform capacity to own identity infrastructure, or products embedding identity where license costs would compound. ## How to Choose Your Okta Alternative Start with which searcher you are. **If you're leaving Okta over cost and you're on Google Workspace or Microsoft 365:** you may not need another IdP at all. The identity provider you already pay for handles authentication; [Cakewalk](https://www.cakewalk.security/) adds the lifecycle automation, access reviews, audit evidence and [AI agent control](https://www.cakewalk.security/control-agent-access) that were the expensive part of the Okta bill. This is the most efficient path for most mid-market teams and the cheapest to evaluate, since Cakewalk is free to get started. **If you need a full IdP replacement:** Microsoft Entra ID for Microsoft-first organizations, Google Cloud Identity for Google-first ones, JumpCloud if you want device management in the same platform, OneLogin for cost-efficient SSO/MFA, Ping for enterprise hybrid complexity. **If your driver is security depth:** Duo for authentication and device trust, CyberArk if privileged access and machine identity are the real problem. **If you're consolidating HR and IT:** Rippling, with the understanding that you're adopting an ecosystem. **If you have the engineering capacity to own it:** Keycloak, with eyes open about operational cost. And whichever IdP path you take, the governance question doesn't go away. Authentication platforms tell you who logged in. Auditors, boards and increasingly your own AI agents demand answers authentication can't give: who approved this, when was it reviewed, what can this agent touch. That's the layer worth solving first, because it's the layer that shows up in audit findings. For a deeper look at the platforms built for that problem, see our guide to the [top 10 AI agent security tools for access management](https://www.cakewalk.security/blog/top-10-ai-agent-security-tools-access-management-2026). [See what's actually in your stack with Cakewalk, free](https://www.cakewalk.security/control-agent-access) ## FAQ ### What Is the Best Alternative to Okta? It depends on which part of Okta you're replacing. For authentication (SSO and MFA), Microsoft Entra ID and Google Cloud Identity are the most common replacements because most organizations already license one of them. For the lifecycle, governance and access review capabilities that sit in Okta's premium tiers, [Cakewalk](https://www.cakewalk.security/) is the strongest mid-market alternative: it runs on top of the IdP you already own and adds automated provisioning, access reviews, audit evidence and [AI agent access control](/glossary/ai-agent-access-control), free to get started. ### Can I Replace Okta Without Buying Another Identity Provider? Often, yes. If your organization runs Google Workspace or Microsoft 365, you already have a functioning IdP with SSO and MFA. Teams in that position frequently discover they were using Okta primarily for lifecycle management and governance, which a dedicated governance platform handles at a fraction of the stacked-tier cost. The evaluation is straightforward: list what you actually use Okta for, and check how much of it is authentication versus everything else. ### Is There a Free Okta Alternative? Several options have free entry points, with different shapes. Keycloak is fully open source but self-hosted, meaning you pay in operations instead of licenses. Cisco Duo is free up to 10 users. JumpCloud and Google Cloud Identity have limited free tiers. [Cakewalk is free to get started](https://www.cakewalk.security/control-agent-access) as a commercial platform, including its AI agent access product, which makes it the only free path to governance capabilities rather than just authentication. ### How Much Does Switching From Okta Actually Cost? The license price is the visible part. The hidden costs are migration (re-federating apps, re-enrolling MFA, retraining users) and the capability gaps you discover after switching. IdP-to-IdP migrations for a mid-market company typically run one to three months of project work. The governance-layer path (keeping your IdP, adding Cakewalk) avoids the migration entirely, which is why it's usually the faster evaluation: nothing gets re-federated, and the [free tier](https://www.cakewalk.security/control-agent-access) means the pilot costs an afternoon. ### Which Okta Alternatives Handle AI Agent Access? This is the newest gap in the category. Okta shipped its own agent identity product in April 2026 (as an additional product on Okta pricing). Cisco is integrating Astrix Security after its May 2026 acquisition, and CyberArk has a credible machine identity story via Venafi. Among the alternatives in this guide, [Cakewalk's agent access control](https://www.cakewalk.security/agent-access-management) is the most direct answer: a runtime gateway that evaluates every agent action against policy, injects vaulted credentials the agent never sees and logs the full delegation chain. Traditional IdPs on this list (OneLogin, Ping, JumpCloud, Keycloak) don't yet ship dedicated agent access products. ### Do I Still Need Governance If I Switch to Entra or Google? Yes, and this is the most common post-migration surprise. Entra and Google handle authentication well, but access reviews, joiner-mover-leaver automation across your full SaaS stack and audit evidence for SOC 2 or ISO 27001 sit either in expensive higher tiers (Entra ID Governance) or outside the product entirely (Google). Teams that switch IdPs to save money and then hit an audit usually end up adding a governance layer anyway. Evaluating both moves together, rather than sequentially, avoids paying for the discovery twice. ### How Long Does It Take to Migrate off Okta? For a full IdP swap: typically one to three months for a mid-market company, covering app re-federation, MFA re-enrollment and user communication, with complex estates running longer. For the governance-layer path, there's no migration at all: your IdP stays, and a platform like [Cakewalk](https://www.cakewalk.security/) connects alongside it, with most teams live in 1-2 weeks. That asymmetry is worth weighing when the pain driving the search is cost or governance rather than authentication itself. --- # AI Gateway Security: The New Attack Surface and the New Control Point _Darktrace found a company's AI gateway quietly working for an attacker. What a gateway holds between calls decides how bad a break-in gets._ By Gil Röder, CPO & Co-Founder Published: 2026-07-30 Source: https://www.cakewalk.security/blog/ai-gateway-security-attack-surface --- ## TL;DR - In July 2026, Darktrace found attackers mining cryptocurrency on a company's server. That server was its AI gateway, holding permanent access to Amazon's AI models and checking nothing about who was calling. - Two kinds of gateway appear here. An AI gateway carries a company's calls to AI models, while an MCP gateway carries what its agents do inside the company's apps. - Cakewalk governs agent access at the MCP gateway because one place can check every call. Enforcing app by app only ever covers the apps that built the hooks themselves. **Bottom line:** What the gateway is built to hold decides whether that single point is the softest target or the best place to enforce the rules. ## The Breached AI Gateway Held Standing Access In July 2026, Darktrace disclosed a break-in at one of its customers. An attacker had installed a cryptominer on one of the company's servers, which is what Darktrace's monitoring caught. That server was the company's own [AI gateway](/glossary/ai-gateway), a LiteLLM gateway wired to Amazon Bedrock.[1] **Definition: AI gateway.** One server that every application in a company sends its model calls through. It holds the model-provider credentials, routes each call to the chosen model and applies rate limits, spend tracking and logging in one place. Teams run one so they can switch providers and see usage without changing every app. LiteLLM is an AI gateway, open-source software that routes an application's calls to language models. Every model call the company made went through this gateway. Its SSH port was open to the entire internet. Darktrace recorded a large number of login attempts against it, almost all from a single address, which is what an automated password-guessing attack looks like. Darktrace could not confirm how the attacker finally got in. What made it worth taking was what the AI gateway carried. The AI gateway held standing access to Amazon Bedrock through an instance profile, which attaches AWS permissions to the server itself. Anything running on that server could call Bedrock without a password or a key file. The AI gateway also checked nothing about who was calling, because its job was to forward requests. One exposed login was therefore worth everything behind it. The mining was the only damage Darktrace confirmed. The attacker also tried to invoke Bedrock models and to create new AWS users, though Darktrace found no evidence that either succeeded. The access they held was worth far more than the compute they took. > A compromise may provide attackers with access not only to compute resources, but also to cloud identities, model services, sensitive prompts, and other connected systems. _Darktrace_ The LiteLLM AI gateway was worth taking because a gateway concentrates access by design. The same concentration makes a gateway the one place where every call can be governed. What a break-in is worth comes down to what the gateway was built to hold. ### How the Ungoverned AI Gateway Is Built _Because the credential sits inside the AI gateway, everything behind it comes with the server._ _Figure: AI gateway break-in, ungoverned: a LiteLLM proxy holds a standing credential available to anything on the instance, so one break-in reaches cloud credentials, model services, prompts and connected systems._ ## The Same Gateway Shape Is Going Mainstream The largest cloud and identity platforms are converging on a single gateway for every agent call. They committed to the architecture before deciding what that gateway is allowed to hold. Google's Gemini Enterprise Agent Platform places an Agent Gateway between agents and everything they access, with policy evaluated at the gateway.[2] Amazon Bedrock's AgentCore works the same way, with a policy layer that checks each call before it reaches the app.[3] Cloudflare routes agent traffic through [Model Context Protocol](/glossary/model-context-protocol) (MCP) server portals that attach the credential and proxy the request on the agent's behalf[4] while Okta has opened its own Agent Gateway to customers as a research release.[5] The convergence is correct: enforcing one policy across every agent action requires one place to enforce it, because the alternative scatters policy app-by-app until nobody can audit it. When every credential and every call runs through one gateway, it holds more access than any employee, [service account](/glossary/service-account) or app in the company. Each new gateway also adds another single point of failure. All four have committed to enforcement at the gateway, though what it keeps between calls is still an open question. Cakewalk answers it with [zero standing access](/glossary/zero-standing-permissions). ## A Governed Gateway Holds No Standing Access Where the LiteLLM AI gateway carried model traffic, Cakewalk's [MCP Gateway](https://www.cakewalk.security/docs/ai-agent-access/concepts/the-mcp-gateway) [governs agent access](/blog/human-agent-system-working-model-governing-agent-access) to apps. The same risk reaches both, because it follows from concentrating access in one place rather than from any one product category. **Definition: MCP gateway.** One endpoint an agent connects to instead of connecting to each MCP server itself. It presents the tools from every connected server as a single list, holds the credentials those servers need and decides per tool call whether the call goes through. An AI gateway concentrates traffic the same way while carrying prompts to model providers rather than an agent's tool calls to a company's apps. An agent on Cakewalk never holds a credential of its own. It starts every call with nothing it can use and gets no blanket grant it could carry into the next one. Every tool call is evaluated fresh against policy before it runs and resolves to one of three outcomes: auto-approve, escalate to a human or deny. When a call escalates, the session suspends mid-task and waits. The approval request appears inline in the agent client through [elicitation](/glossary/elicitation), a method the [MCP spec](https://modelcontextprotocol.io/specification/2026-07-28) defines and goes to the person the agent acts for. It resumes only if they approve. A refusal denies the call, as does silence: an unanswered request dies after five minutes and is logged as a timeout. Every agent action lands in one of four types: read, write, destructive or external. The tool's vendor declares the MCP annotations and Cakewalk maps them onto those four types. A tool that declares none is treated as destructive, which the default policies deny until an admin classifies it. The type sets the default outcome. Reads are auto-approved, writes wait for human approval and destructive or external actions are denied outright. An admin can change any of those defaults and can add custom policies that outrank them. Policies always produce a decision as the four defaults cover every action type and cannot be removed. If the engine itself is unreachable, the gateway denies rather than waving the call through. There is no fail-open path. The engine is [Open Policy Agent](/glossary/opa-rego) (OPA), with policies expressed in its Rego language. Admins configure those policies in the Cakewalk policy builder while Rego runs underneath. Security teams already run OPA in front of Kubernetes and service traffic. In the gateway it evaluates every tool call before anything moves upstream. The evaluation is deterministic, which means the same call in the same context yields the same outcome every time. [Runtime Governance: The Missing Layer for Agent Access](/blog/governing-the-new-frontier-the-missing-layer-for-agent-access) walks through that decision flow in full, including why no language model sits anywhere in it. The approval flow has one exception. It arises when an agent client does not yet support elicitation and so cannot show the approval prompt. The gateway then denies any call that requires approval, unless an admin deliberately opts to auto-approve those calls instead. An agent never receives a real credential. The gateway resolves the token on the server side and injects it into the outbound request without ever showing it to the agent or the model. A [prompt-injected](/glossary/prompt-injection) agent cannot leak a token it never held. The credential itself is stored with [envelope encryption](https://www.cakewalk.security/docs/ai-agent-access/concepts/trust-and-security), encrypted under AES-256-GCM with its own data key wrapped by an external key management service. One broken key exposes at most one credential. Cakewalk made that trade deliberately: the gateway persists the credential so the agent side holds nothing. Every call the gateway allows produces one permanent [audit event](https://www.cakewalk.security/docs/ai-agent-access/concepts/audit-log): who acted, what they did, against which connection, which policy fired and its outcome, with a timestamp. Each action traces to a named person. An agent inherits only what that person may use, which the gateway verifies on every call. Revoking their access denies the agents acting for them at the next call. The record also feeds forward, which is why a company can replay the last 30 days of recorded calls against a policy change and see which past decisions would flip before the change goes live. A governed gateway is not unbreakable. It has to assume an attacker can get in. What changes is what that attacker walks away with. [An attacker who breaks in the same way](/blog/jadepuffer-agentic-ransomware) finds no standing access to inherit, no agent-usable credential to steal and every action still gated and recorded. Even in the worst case, the one Darktrace described, a break-in here is worth a fraction of what it was worth there. ### How the Governed Gateway Is Built _Because the credential never reaches the agent, a break-in inherits nothing and every decision is still recorded._ _Figure: AI gateway break-in, governed: the Cakewalk MCP Gateway injects a credential only for the call in flight, so a break-in reaches only the one scoped app, and every decision is recorded._ ## Concentration Becomes Control Putting agent access in one place creates a target. Every control point does, which is why concentration itself is not the problem. What that target is worth to an attacker who seizes it is a design choice. The same concentration that made the LiteLLM AI gateway worth attacking is what makes a governed gateway the one place to govern. Governing here covers what the agent does in the company's apps. What it does inside its own runtime stays outside the gateway's view. Those app calls are where a break-in turns into damage. That is why Cakewalk builds at the gateway rather than app by app, where enforcement waits on every app to ship its own hooks and only ever covers the ones that did. A gateway that holds nothing standing, checks every governed call as it happens and records the result turns that concentration into control. The position that could have opened everything up becomes the control point agent access has been missing. ## References 1. Darktrace (2026). When AI Infrastructure Becomes Part of the Attack Surface. 2. Google Cloud (2026). Agent Gateway overview, Gemini Enterprise Agent Platform documentation. 3. AWS (2026). Amazon Bedrock AgentCore Developer Guide: Policy. 4. Cloudflare (2026). MCP Server Portals, Cloudflare One documentation. 5. Okta (2026). Okta Agent Gateway: Secure Runtime AI Agent Governance. --- # Agent Cake Now Signs In Through Google SSO _Agent Cake, Cakewalk's AI provisioning agent, now signs in through Google SSO. Apps that enforce Google sign-in stay inside auto-provisioning, with no password kept alive outside the company's identity provider._ By Gil Röder, CPO & Co-Founder Published: 2026-07-30 Source: https://www.cakewalk.security/blog/auto-provisioning-google-sign-in --- ## Auto-Provisioning Has Depended on Two Standards Agent Cake, Cakewalk's AI provisioning agent, now signs in through Google [SSO](/glossary/sso). Apps that enforce Google sign-in therefore stay inside [auto-provisioning](https://www.cakewalk.security/auto-provisioning) instead of going back to somebody creating accounts in them by hand. We ask every new customer which apps their identity platform provisions today. The answer is usually a short list. That short list has a cause, which sits in the two standards auto-provisioning has depended on. ## SCIM Covers a Fraction of the Apps a Company Runs [System for Cross-domain Identity Management](/glossary/scim) (SCIM) is the API standard for creating, updating and deleting accounts. It works well where it exists, which is the problem. A [Stitchflow analysis](https://www.stitchflow.com/blog/scim-vs-sso-tax-manual-provisioning) of 721 SaaS apps found that 42% put SCIM behind enterprise pricing, while 57% do not offer it at any price. That left nine apps in the sample including it on a base tier. A platform that provisions through SCIM alone therefore automates the apps a company already pays the most for. ## Just-in-Time Provisioning Leaves the Departure Unhandled Just-in-time provisioning takes another route. When somebody signs in through Security Assertion Markup Language (SAML), the app creates the account out of the login itself. That covers the account and little else, because the new user typically lands on a default role, so an admin still sets the real permission level by hand. And because a login is the trigger, nothing fires when somebody leaves. Those accounts therefore stay behind as dormant access with no owner, which is what an auditor finds in an [access review](https://www.cakewalk.security/user-access-review-software). ## Agent Cake Provisions the Apps That Never Offered an Interface Agent Cake provisions an app in [one of two ways](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/how-it-works), depending on what the app exposes. Where a provisioning API comes with the app's standard plans, Agent Cake uses it. Where that API exists only on an enterprise tier or not at all, Agent Cake signs in with a scoped [service account](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/how-it-works/set-up-service-accounts) and performs the change directly. A grant then creates the account and assigns its permissions, while an offboarding suspends or removes it. Every run appears in the app's [execution log](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/monitoring-and-logs/execution-logs). Because Agent Cake asks the app for nothing, the app needs no SCIM support and the company needs no upgrade to its enterprise plan. ## Apps Behind Google SSO Stay Automated Enforcing single sign-on is good security, because it puts every login behind one [identity provider](/glossary/identity-provider), so access can be cut off in one place when somebody leaves and no app keeps a password of its own. It also removes the app's own password form, which leaves the admin account with Google as its only way in. Before this release, that left two options. Re-enabling password login for a shared admin account puts a credential outside the company's identity provider, which puts it outside offboarding too. The alternative keeps that credential out while it hands the app back to a person, so every app the SSO policy covers becomes another app where somebody creates each account by hand and removes it by hand when that person leaves. Agent Cake now signs in through Google instead. An app therefore stays automated after its SSO policy goes on, without any password staying alive outside the company's identity provider to keep it that way. ## One Dedicated Google Account Covers Every Wired App Agent Cake signs in with a dedicated Google Workspace account that an admin creates as a [service account](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/how-it-works/set-up-service-accounts), never with a person's own login. That account needs no privileges in Google Workspace itself, because Agent Cake does no provisioning inside Google. Its permissions live in the target app instead, where it needs enough rights to create users and assign roles. One account then covers every app wired for it, so an admin connects it once instead of creating a separate [service account](/glossary/service-account) and password for each app Agent Cake provisions. Admins can review the account, scope it, rotate it and switch it off. It also appears in an offboarding run like any other account. There is no [OAuth](/glossary/oauth) consent screen and no token on the company's Google Workspace, so Cakewalk holds no standing permission to call Google's own APIs for mail, files or directory data. The [Sign in with Google guide](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/how-it-works/sign-in-with-google) has the setup steps and the account requirements. ## The Credentials Stay Encrypted Until a Run Needs Them The account keeps 2-Step Verification switched on. When Google asks for the second factor at sign-in, Agent Cake answers with a time-based one-time password, which is the rotating code an authenticator app generates. Some apps also enforce their own two-factor authentication on top of the Google sign-in, which takes a second code belonging to the app rather than to Google. The [multi-factor authentication guide](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/how-it-works/multi-factor-authentication) covers both. Credentials are encrypted in the browser before they are sent, so they never travel in plaintext. Cakewalk then stores them in a database dedicated to that company and decrypts them in memory only at the moment a provisioning run uses them, through Amazon KMS, which logs every decryption event. Nothing is written or logged in plaintext. The decrypted values are discarded when the job finishes, as the [security and data protection guide](https://www.cakewalk.security/docs/how-to-guides/auto-provisioning/how-it-works/security-and-data-protection) sets out in full. ## Agent Cake Covers the Apps SCIM Prices Out Agent Cake provisions apps that never shipped SCIM as well as apps whose vendor sells it on the enterprise tier, so a company covers its stack without buying an enterprise plan per app to turn provisioning on. IT and app owners therefore stop spending hours creating accounts by hand and removing them one at a time when somebody leaves. Apps behind a Google SSO policy now belong in that set. --- # An Attacker Turned Off the Hermes AI Agent's Approval Prompt _On July 23, 2026 the threat-intelligence firm Hunt.io reported an attacker running Hermes, a widely used open-source AI agent, in YOLO mode against Thailand's Ministry of Finance. Because that setting clears the approval checks on dangerous commands, nobody watched each step._ By Johannes Keienburg, CEO & Founder Published: 2026-07-28 Source: https://www.cakewalk.security/blog/hermes-agent-yolo-mode-attack --- ## One Setting Removed the Approval Step An attacker working against Thailand's Ministry of Finance ran an open-source AI agent with its approval checks switched off. The threat-intelligence firm Hunt.io reported the operation on July 23, 2026, after finding the agent's own logs on a server the attacker had left exposed. The agent is Hermes, running a setting called YOLO mode. > Hermes output logs show the operator ran the agent in unattended or YOLO mode, bypassing approval prompts for commands that could be considered dangerous. _Hunt.io_ Between July 9 and July 13 Hunt.io archived three open directories on a Hong Kong server. They held 585 files and 470 MB of attack code and stolen credentials, along with the agent's logs. Five of those logs record what the agent did. It scanned for kernel vulnerabilities, enumerated services, listed the programs that run with elevated privileges (SUID and SGID binaries) and walked the file system. The fifth covers a ministry web directory holding personnel records going back to 2012. Hunt.io saw no sign that any of those files left the network. ## A Person Still Chose the Target The operator instructed the agent, handed it a privilege-escalation script customized for ministry systems and let it work without stopping to ask. Hunt.io describes an operator who invested significant preparation into penetrating a single government target. Hunt.io also notes the project passed 140,000 GitHub stars by July 2026 and is among the most widely deployed publicly available agent frameworks. > Most of the tools here are ones we have seen before. The combination is what stands apart: an AI agent coordinating the work, a cross-platform implant holding access, and scripts written for this specific target. _Hunt.io_ The approval prompt is a weaker control than it sounds. Hermes defaults to what its documentation calls smart approvals, where an auxiliary model rates each flagged command, clears what it reads as low risk, denies what it reads as clearly dangerous and passes only the uncertain cases to a person. A mode that asks about every dangerous command exists, though someone has to turn it on. YOLO mode drops the prompts entirely for that session. Both the agent and its approval logic ran on infrastructure the operator controlled. Nothing on the ministry's side registered a decision. Those control panels are not hard to find. One Hunt.io banner query returned 5,900 events for exposed Hermes panels in a single month. Any company running an agent framework can check its own approval mode tonight and whether its panel answers from the public internet. > Because this attack ran on infrastructure the operator controlled, no company control sat in its path. What transfers is where the approval sits. Inside a company an agent acts for a named person and holds no standing access, only what the task needs. The gateway evaluates every action as it happens. One record holds what was allowed, denied or escalated. Put that evaluation between the agent and the app and no setting on the agent's side can clear it. _Comment from Gil Röder, CPO & Co-Founder_ Source: Hunt.io, "[Thailand's Ministry of Finance Targeted With Hermes AI Agent Running Unattended, Hades Implant Staged](https://hunt.io/blog/thailand-ministry-finance-targeted-with-hermes-ai-agent)", July 23, 2026. --- # An AI Agent Breached Hugging Face to Cheat a Benchmark _In July 2026 Hugging Face disclosed that an autonomous AI agent, not a human attacker, broke into its infrastructure over a weekend and harvested credentials. Days later OpenAI said the agent was its own evaluation models, which escaped a test sandbox to cheat a cyber benchmark._ By Johannes Keienburg, CEO & Founder Published: 2026-07-22 Source: https://www.cakewalk.security/blog/ai-agent-breached-hugging-face --- ## No Human Was Behind the Keyboard Hugging Face hosts much of the AI industry's public models and datasets. In July 2026 Hugging Face disclosed a breach unlike the ones before it: from start to finish the intruder was an autonomous AI agent, not a person at a keyboard. The agent accessed a limited set of internal datasets and several service credentials before the company's own security team contained it. > This one was different from anything we had handled before in one important way: it was driven, end to end, by an autonomous AI agent system. _Hugging Face_ The way in was mundane. A malicious dataset carried code that ran on a processing worker through two paths, a remote-code loader and a template injection in a dataset config. From there the agent escalated to node-level access. It then harvested cloud and cluster credentials and moved across internal clusters over a weekend. That activity left an attacker action log of more than 17,000 recorded events. The agent never touched public models, datasets or Spaces, and the software supply chain came back clean. ## The Attacker Was an Evaluation That Went Too Far Days later OpenAI said the agent was its own. In a statement on July 21, OpenAI said the activity came from two of its own models. They were GPT-5.6 Sol and a more capable pre-release model, run for a cyber-capability benchmark with their cyber refusals turned down. According to OpenAI, the models were boxed in a test environment. To escape, they found and exploited a zero-day in a package-registry cache proxy that opened a path to the internet. From there, OpenAI said, they inferred Hugging Face hosted the benchmark's answers and broke into its production to take them. > Advanced models can discover and exploit novel attack paths in real-world systems without source-code access. _OpenAI_ That is the uncomfortable part for anyone deploying agents. Nobody told the models to steal. Their job was to solve a test, and they chained stolen credentials and a zero-day into a real remote-code path to do it. An agent with a working credential and no check on each action moves as fast and as far as that credential allows. The control that would have stopped it sits outside the model, at the moment of each action, well past the prompt that set the goal. > An agent always acts for a named operator, so its access should stay no wider than the task needs, re-checked at runtime on every action instead of handed over as a standing credential. Here the operator was only a benchmark, and the agent still chained real credentials into a real breach. Nothing re-evaluated the action, so nothing stopped it. Govern each action, keep one record of what was allowed, denied or escalated, and a stolen credential stops being a skeleton key. _Comment from Gil Röder, CPO & Co-Founder_ Source: Hugging Face, "[A New Kind of Security Incident](https://huggingface.co/blog/security-incident-july-2026)", July 16, 2026. --- # Top 5 AI Agent Access Control Platforms in 2026 _How the five major platforms control AI agent access in 2026. Cakewalk's runtime policy gateway compared against Okta, SailPoint, Wiz and Cisco-Astrix, with an honest look at what each one enforces._ By Gil Röder, CPO & Co-Founder Published: 2026-07-22 Source: https://www.cakewalk.security/blog/ai-agent-access-control-platforms --- Machine identities now outnumber humans 82 to 1, according to CyberArk's 2025 Identity Security Landscape. IDC projects over 1 billion AI agents deployed worldwide by 2029. And in most organizations, those agents authenticate with credentials nobody rotates, hold permissions nobody reviews and take actions nobody logs. The gap isn't theoretical. When an agent acts inside Salesforce or GitHub today, the [audit log](/glossary/audit-trail) records the human whose [OAuth](/glossary/oauth) token it borrowed. That's not an audit trail. It's a list of names. When an employee leaves, HR offboards them and IT revokes their access, but the agents they set up keep running. And when a [prompt injection](/glossary/prompt-injection) lands, the attacker inherits whatever standing access the agent was holding at that moment. [AI agent access control](/glossary/ai-agent-access-control) is the discipline of closing that gap: evaluating every agent action against policy before it executes, mediating credentials so agents never hold real keys and logging every decision with the full delegation chain. This piece compares how the five platforms that dominate the conversation actually control agent access, because the question security teams keep asking isn't "what platforms exist" but "can't the platform we already own do this?" Okta, SailPoint, Wiz and Cisco (via Astrix) all say yes. What each one enforces, and where enforcement stops, differs more than the marketing suggests. For a broader survey of the category including the mid-market and pure-play options, see our guide to the [top 10 AI agent security tools for access management](/blog/top-10-ai-agent-security-tools-access-management-2026). Cakewalk is first because it's the only platform on this list with a purpose-built runtime policy gateway between agents and apps, free to get started and deployable against your existing stack without replacing anything. ## What Is AI Agent Access Control? Three questions define the category. Where are your agents? What can they access? What are they actually doing with that access? Traditional security platforms answer none of them. Your [IdP](/glossary/identity-provider) knows about the humans. Your CASB knows about the SaaS apps. Neither was built to see an agent spawned inside Cursor that calls a Salesforce API through an [MCP](/glossary/model-context-protocol) server using a token delegated from a sales rep's session. That interaction crosses four trust boundaries and shows up in exactly zero of your existing dashboards. A real AI agent access control platform covers four layers: 1. **Discovery.** Every agent across your stack, in one catalog. The sanctioned Copilot deployment and the ChatGPT connector a marketer wired up last Tuesday. If the platform only sees agents registered through your IdP, it's seeing a fraction of what's running. 2. **Runtime policy enforcement.** Every action evaluated before it executes. Reads auto-approve, writes escalate, destructive actions deny. Enforcement has to be deterministic: no LLM should sit in the policy decision path, because probabilistic enforcement is not enforcement. 3. [**Credential mediation**](/glossary/credential-mediation)**.** Agents should never hold real credentials. Tokens live in a vault, get injected per tool call at proxy time and are held nowhere between calls. When a prompt-injected agent leaks what it's holding, it leaks a reference ID, not a key. 4. **Identity-linked audit.** Every call records the human who delegated, the agent that ran and the policy that fired. And the lifecycle closes the loop: offboard the human in your HRIS and their agents get revoked too. Platforms that cover discovery and posture but not runtime enforcement are visibility layers. Valuable, but they tell you about the problem rather than stopping it. Platforms that cover identity registration but not credential mediation still leave real keys in agent hands. The comparison below is honest about which platforms cover which layers. ## AI Agent Access Control Platform Comparison | Platform | Best fit | Approach | Free tier? | | --- | --- | --- | --- | | Cakewalk | Fast-moving B2B security and IT teams | Runtime policy gateway with credential mediation and identity-linked audit | Yes, free to get started | | Astrix Security | Cisco-ecosystem enterprises | NHI security platform with Agent Control Plane, being acquired by Cisco ($400M) | No (enterprise sales) | | Okta for AI Agents | Okta-first enterprises | Agent registration in Universal Directory with lifecycle governance | No (Okta platform licensing) | | SailPoint Agent Identity Security | Fortune 500 with existing SailPoint | Agent identity connectors for enterprise platforms (separate license) | No (enterprise sales) | | Wiz AI Security | Cloud-native enterprises on Wiz CNAPP | AI-SPM posture management with agent inventory and attack path analysis | No (CNAPP platform pricing) | ## The 5 Best AI Agent Access Control Platforms ### 1. Cakewalk [Cakewalk](/) is the policy layer between your company's AI agents and its apps. Every action evaluated, every credential mediated, every decision logged. It's the first access layer built specifically for AI agents rather than adapted from human identity infrastructure, and the only platform on this list that's free to get started. The architecture is a runtime gateway. Every agent action passes through the Cakewalk Gateway before it can touch your company's apps: the tool call is intercepted, evaluated against your policies, a scoped credential is injected and the decision is logged. The whole sequence completes in under a second, from prompt to audited action. Key capabilities: - [**Policy engine**](/glossary/policy-engine)** with per-action rules.** Reads auto-approve. Writes require approval. Destructive actions deny. The [MCP Gateway](/glossary/mcp-gateway) enforces policies in real time, and you can build them visually or in code. Decisions are deterministic, with no LLM in the enforcement path. - **Credential mediation through the Cakewalk vault.** Agents never see real credentials. Tokens stay in the vault, get pulled per tool call, injected at proxy time and held nowhere between calls. A prompt-injected agent leaks a reference ID, not a key. This single design decision removes the most dangerous failure mode in agent security. - **Agent discovery with one catalog and one kill switch.** Cakewalk finds every agent your team runs across any platform: Cursor, Claude, Microsoft Copilot, ChatGPT, Gemini and the long tail. One catalog, one policy set, one place to revoke everything if something goes wrong. - **Just-in-time access.** Each agent gets exactly the access the task needs, only as long as it needs it, revoked the moment the work is done. No standing permissions accumulating in the background. - **Identity-linked lifecycle.** Every call records the human who delegated, the agent that ran and the policy that fired. Offboard the human in your HRIS and their agents get revoked automatically. This closes the [shadow AI](/glossary/shadow-ai) loop that catches most organizations: HR offboards humans, IT revokes their access and the agents they set up keep running forever. - **350+ integrations.** Works with the agents and apps you already use, without replacing anything. [See the full integration list](/integrations). Cakewalk is [ISO 27001](/glossary/iso-27001) certified, [GDPR](/glossary/gdpr) compliant and rated 4.6/5 on G2 and 4.7/5 on Capterra. Teams at ElevenLabs, Mentimeter, PolyAI, Dust, FreeAgent, Prolific and Teamtailor already use [Cakewalk Access Management](/human-access-management) to govern human access; the agent product extends the same operating model to AI. [The ElevenLabs story](/customers/how-elevenlabs-automated-access-management-to-keep-up-with-hyper-growth) is worth reading if you're at a high-growth company where agent adoption is outpacing governance. **Trade-offs:** Cakewalk is built for fast-moving mid-market teams, not for Fortune 500 procurement processes with multi-year [IGA](/glossary/iga-identity-governance) consolidation projects. If your primary requirement is deep integration with legacy enterprise identity infrastructure (mainframe connectors, on-prem SAP), the legacy IGA vendors cover ground Cakewalk doesn't aim at. **Best fit:** security and IT teams at fast-moving B2B companies that need to see and control agent access now, not after a two-quarter implementation. Free to start, so the evaluation cost is an afternoon. [Control your agent access with Cakewalk](/control-agent-access) or [see how the product works](/agent-access-management). ### 2. Astrix Security Astrix Security is the [non-human identity](/glossary/non-human-identity) security platform that Cisco announced acquiring for $400M in early May 2026. The product is a credible pure-play in agent [access control](/glossary/access-control): the Agent Control Plane covers discovery, governance, lifecycle management, threat detection and secrets management for [service accounts](/glossary/service-account), [API keys](/glossary/api-key), OAuth tokens and AI agents across cloud, SaaS and on-prem environments. Astrix's strength is the NHI foundation. The platform was built to find and govern the non-human identities that traditional IAM leaves outside the perimeter, and AI agents slot into that model as a new identity type with the same discovery and lifecycle treatment. Threat detection is deeper than most competitors in the category, with anomaly detection on non-human identity behavior. Customers include Xerox and HubSpot. The Cisco acquisition cuts both ways for buyers. Long term, Astrix gains Cisco's distribution and integration into Cisco Identity Intelligence, Duo IAM and Secure Access, which signals durable roadmap investment. Short term, expect integration churn through 2026 and 2027 as the product is folded into Cisco's portfolio, with the usual acquisition-era uncertainty about pricing, packaging and standalone availability. **Trade-offs:** enterprise sales only, no free tier and acquisition-transition risk for the next 12-18 months. The platform's center of gravity is NHI security with agents added, rather than runtime agent access enforcement as the core architecture. **Best fit:** enterprises already in the Cisco security ecosystem, or large organizations that want NHI security with a clear acquirer integration path. ### 3. Okta for AI Agents Okta for AI Agents went generally available on April 30, 2026, as the flagship implementation of Okta's "blueprint for the secure agentic enterprise." The framing is built around three questions: where are my agents, what can they connect to and what can they do? The product treats AI agents as first-class identities within Okta's Universal Directory. Agents get discovered (known and shadow), registered in a single directory and assigned a human owner. Protection comes through [least-privilege](/glossary/least-privilege) access with short-lived credentials instead of long-lived tokens, and governance runs through automated workflows with a full audit trail and instant revocation. In May 2026, Okta extended the product to support any identity provider (not just Okta) and added an Amazon Bedrock AgentCore integration for agents built on AWS. The stats Okta cites for why this matters are striking: 88% of organizations report suspected or confirmed AI agent security incidents, while only 22% treat agents as independent, identity-bearing entities. Okta's answer is to extend the identity fabric that already governs your workforce to cover agents, which is compelling if Okta is already your identity backbone. **Trade-offs:** the product is strongest inside the Okta ecosystem, and pricing sits on top of Okta's existing platform licensing. Runtime enforcement is directory-and-policy driven rather than a proxy gateway, which means credential mediation at the individual tool-call level works differently from gateway-architecture platforms. Organizations not already on Okta are buying into a larger platform commitment. **Best fit:** Okta-first enterprises that want agent governance woven into their existing identity fabric, with the vendor relationship and support structure they already have. ### 4. SailPoint Agent Identity Security SailPoint extended its enterprise IGA platform with Agent Identity Security connectors in 2026, covering discovery and governance of AI agents inside Salesforce, ServiceNow and Snowflake. The company has also formalized an "adaptive identity" strategy positioning the platform around real-time, risk-context-driven access decisions. For the Fortune 500 organizations that already run SailPoint as their identity governance backbone, the agent connectors are the lowest-friction way to bring AI agents inside the existing certification, segregation-of-duties and lifecycle machinery. Agents discovered in the covered platforms get the same governance treatment as human identities: ownership assignment, access certification campaigns and audit-ready reporting through the tooling compliance teams already know. **Trade-offs:** Agent Identity Security requires a separate license on top of the core SailPoint platform. Coverage is currently strongest inside the three named platforms, which leaves the broader agent surface ([MCP servers](/glossary/mcp-server), desktop agents, custom-built agents, the long tail of SaaS) outside the perimeter. Implementation timelines and administrative complexity follow SailPoint's enterprise pattern: quarters, not weeks. For a company that needs to govern Claude Desktop sessions across 300 employees next month, SailPoint is heavy machinery pointed at a different problem. **Best fit:** large regulated enterprises with existing SailPoint deployments, dedicated IAM teams and agents concentrated in Salesforce, ServiceNow and Snowflake. ### 5. Wiz AI Security Wiz AI-SPM extends Wiz's agentless CNAPP into AI security posture management: discovering AI services, models and agents across cloud environments, assessing configurations and mapping attack paths through the Wiz Security Graph. At RSAC 2026, Wiz announced its AI-Application Protection Platform (AI-APP) along with Wiz Security Agents for automated remediation. The posture approach has real strengths. The dynamic AI-Bill of Materials inventories AI frameworks, models, IDE extensions and agent dependencies across your company's cloud estate without deploying endpoint agents. The Security Graph connects agent misconfigurations to live cloud context, so an over-permissioned agent gets ranked by actual [blast radius](/glossary/blast-radius) rather than theoretical severity. Coverage now spans agent studios including AWS AgentCore, Gemini Enterprise Agent Platform, Microsoft Copilot Studio and Salesforce Agentforce. Wiz's own research found at least 57% of organizations have deployed self-hosted AI agent technologies, and the platform is built to find them. The important architectural distinction: Wiz is a posture management product, not an access enforcement product. It tells you an agent is over-permissioned, exposed or misconfigured, and increasingly automates the remediation. What it doesn't do is sit between the agent and the app evaluating each action at runtime. Posture and enforcement are complementary layers; organizations serious about agent security typically want both. **Trade-offs:** AI-SPM isn't a standalone purchase; it's part of a broader Wiz CNAPP commitment, priced accordingly. Coverage is strongest for cloud-native AI workloads and thinner for agents operating purely across SaaS outside the cloud estate. The Google acquisition adds a multi-cloud-parity question that enterprise buyers on AWS and Azure are actively weighing. **Best fit:** cloud-native enterprises already on (or evaluating) Wiz CNAPP that want agent risk correlated with cloud exposure, data sensitivity and lateral-movement context. ## How to Choose an AI Agent Access Control Platform Match the platform to the layer of the problem you're solving first. If your immediate problem is **agents acting without control** (you know they're running, you can't govern what they do), you need runtime enforcement. Cakewalk is the purpose-built option: policy gateway, credential mediation, identity-linked audit, free to start, live in days. If your problem is **non-human identity sprawl** where AI agents are one identity type among thousands of service accounts and API keys, the NHI platforms fit. Astrix (with the Cisco context factored in) covers that ground with strong threat detection. If you're **Okta-first** and want agents governed inside the same identity fabric as your workforce, Okta for AI Agents is the natural extension, especially since the May 2026 update opened it to non-Okta IdPs. If you're a **SailPoint shop** with agents concentrated in Salesforce, ServiceNow and Snowflake, the Agent Identity Security connectors bring them into your existing governance machinery, at SailPoint pace and pricing. If your question is **posture** (which agents exist, what could an attacker reach through them), Wiz AI-SPM maps that better than anyone for cloud-native environments. Pair it with a runtime enforcement layer to act on what it finds. For most fast-moving B2B companies, the practical starting point is visibility plus enforcement in one product, live this quarter, without a procurement cycle. That's the gap Cakewalk was built for. The free agent roll call takes 15 minutes: Cakewalk looks under the hood of your agent stack and shows you who got in, what they're touching and which ones need a shorter leash. [See what your agents are up to](/control-agent-access) ## FAQ ### What Is AI Agent Access Control? AI agent access control is the discipline of governing what AI agents can access and do inside your organization's apps and infrastructure. It covers four layers: discovering every agent across your stack, enforcing policy on each action at runtime, mediating credentials so agents never hold real keys and logging every decision with the full delegation chain back to the human who initiated the work. It's distinct from traditional IAM (built for humans logging in) and from AI model security (built for protecting the models themselves). [Cakewalk's control layer for agent access](/agent-access-management) is purpose-built for this category. ### What's the Difference Between AI Agent Access Control and AI Agent Access Management? The terms overlap heavily and vendors use them interchangeably, but there's a useful distinction. Access management covers the full lifecycle: discovering agents, provisioning their access, reviewing it and revoking it. Access control is the enforcement layer inside that lifecycle: the mechanism that approves, escalates or denies a specific agent action at the moment it happens. A platform can do access management without real-time control (govern the credentials, but not the individual actions), which is where several platforms in this comparison sit. Cakewalk does both, with the control layer (runtime gateway, per-action policy, credential mediation) as the architectural core. ### What's the Difference Between Posture Management and Runtime Enforcement for Agents? Posture management platforms (like Wiz AI-SPM) inventory your agents, assess their configurations and map what an attacker could reach through them. Runtime enforcement platforms (like Cakewalk) sit in the path of each agent action and approve, escalate or deny it against policy before it executes. Posture answers "where are we exposed?" Enforcement answers "stop that action right now." Mature programs run both: posture to find and prioritize risk, enforcement to prevent the risky action from completing. ### How Does Credential Mediation Protect Against Prompt Injection? Prompt injection tricks an agent into doing something its operator didn't intend, and the blast radius depends entirely on what the agent is holding when the injection lands. If the agent holds a real, long-lived API key, the attacker inherits it. With credential mediation, tokens stay in a vault and get injected per tool call at proxy time; the agent itself holds only a reference ID. A prompt-injected agent can leak that reference, but the reference is useless outside the gateway, and the gateway is still enforcing policy on every call. It doesn't prevent injection, but it caps what injection can steal. ### Can These Platforms Enforce Policy on MCP Tool Calls? This is the question to make vendors demonstrate live, because MCP has become the dominant way agents access tools in 2026 and "MCP support" often means discovery, not enforcement. Cakewalk's gateway enforces policy on MCP tool calls directly: the call is intercepted, evaluated and executed with an injected credential, which is the architecture the protocol effectively demands. Okta's [Cross App Access](/glossary/xaa-cross-app-access) (XAA) protocol takes a standards-based approach to agent-to-app connections. Wiz discovers MCP connections as part of its AI inventory but doesn't sit in the enforcement path. In an evaluation, ask the vendor to block a specific MCP tool call by policy while allowing another from the same agent. That single demo separates control platforms from visibility platforms. ### Which AI Agent Access Control Platforms Are Free? Cakewalk is free to get started, including a free 15-minute agent roll call that inventories the agents running across your stack. It's the only platform on this list with a free entry point. Astrix, Okta for AI Agents, SailPoint Agent Identity Security and Wiz AI-SPM all require sales engagement, and in the case of Okta, SailPoint and Wiz, the agent capabilities sit on top of a broader platform license. ### How Quickly Can These Platforms Be Deployed? Cakewalk deploys in days against your existing stack, with 350+ integrations and no rip-and-replace. Okta for AI Agents deploys quickly for existing Okta customers, longer for organizations adopting Okta alongside it. Wiz AI-SPM produces findings fast (agentless architecture) for teams already on Wiz. Astrix and SailPoint follow enterprise implementation patterns measured in weeks to quarters. As a rule, the products built as extensions to platforms you already run deploy at the speed of that platform; the purpose-built products deploy at their own speed, which for Cakewalk means the same week you start. --- # Where AI Expands Access, Breaches Run Four Times the Rate _Two 2026 surveys, from Netwrix and ISACA, point to the same gap: companies are giving AI access faster than they can govern or revoke it. Netwrix links wider AI access to a higher breach rate. ISACA found most security teams cannot say how fast they could halt an AI system gone wrong._ By Johannes Keienburg, CEO & Founder Published: 2026-07-14 Source: https://www.cakewalk.security/blog/ai-access-outpaces-governance --- ## Access Is Outrunning the Ability to Govern It Two 2026 surveys, one from a security vendor and one from an independent professional body, measured how companies are handing access to AI. In June, the identity-security firm Netwrix reported on 2,317 security professionals across 1,889 organizations. In May, the IT governance association ISACA polled more than 3,400 practitioners worldwide. Read together, they describe one gap: companies are giving AI and agents access to their systems faster than they can govern or take it back. > Among organizations where AI significantly expanded the number of identities requiring access, breach rates reached 43% over the past twelve months, compared with 11% where AI had not materially changed access patterns. _Netwrix 2026 Data and Identity Security Report_ Netwrix, which sells [non-human-identity](/glossary/non-human-identity) governance and access products, frames that as a correlation, not proof that AI caused the breaches. The rest of its data points at why the gap exists. Only 19% of organizations say they fully govern their non-human identities, the [service accounts](/glossary/service-account) and agent credentials that now act inside company systems. And 76% cannot immediately revoke standing access once it is no longer needed. Access goes in fast and stays. ## Most Teams Can't Say How They Would Stop It The ISACA poll measured the other half of the problem, which is control after AI is deployed. More than half of the professionals surveyed, 56%, did not know how long it would take to halt an AI system during a security incident. > 39% say they do not know whether they have a documented process for shutting down or overriding AI systems if things go wrong. _ISACA 2026 AI Pulse Poll_ Adoption is not what lags. In the same poll, 38% of organizations reported having a formal, comprehensive AI policy, up from 28% a year earlier. Companies are writing the policies. What is missing is the ability to stop or scope what the AI does once it is already running. Both reports land in the same place. Companies are granting AI access at the speed of adoption and governing it at the speed of paperwork. The access is standing, broad and hard to pull back. In Netwrix's data, that tracks with a higher breach rate. > The two reports name the same gap from opposite ends. A company cannot revoke access it never scoped and cannot halt an agent it cannot see acting. We build for the reverse. An agent acts for the person who sent it, holds no standing access and takes on only the least each task needs. Every action is checked as it happens and recorded once. When the task ends, there is nothing to pull back, because the access was never left standing. _Comment from Gil Röder, CPO & Co-Founder_ Source: Netwrix, "[2026 Data and Identity Security Report](https://netwrix.com/en/resources/research/2026-data-and-identity-security-report/)", June 2026. ISACA, "[2026 AI Pulse Poll](https://www.isaca.org/about-us/newsroom/press-releases/2026/ai-use-accelerates-while-governance-and-roi-lag-says-new-isaca-research)", May 2026. --- # An AI Agent Ran a Ransomware Attack on Its Own _JadePuffer is what the security firm Sysdig calls the first ransomware attack run start to finish by an AI agent, with no human directing it. The agent broke into a server, stole credentials, spread through the network and locked a company's database on its own._ By Johannes Keienburg, CEO & Founder Published: 2026-07-08 Source: https://www.cakewalk.security/blog/jadepuffer-agentic-ransomware --- For the first time, researchers have documented an AI agent running a full ransomware attack by itself. In July 2026, the security firm Sysdig published the case and named it JadePuffer. The agent got in through Langflow, an open-source framework for building AI agents. It exploited a flaw (CVE-2025-3248) that let it run code without logging in. ## One Agent Did the Whole Attack A ransomware attack normally takes a team of people. This time one AI agent did all of it. > An autonomous agent reasoned about its targets, harvested and reused credentials, moved laterally, established persistence, and destroyed a database, narrating its own intent the entire way. _Sysdig Threat Research Team_ It even fixed its own mistakes. When a login failed, the agent found the problem and had a working fix in 31 seconds. It locked 1,342 records in the company's database. The agent made the key that could unlock them and threw it away. Now the data is gone for good, even if the ransom is paid. ## Now It Costs Almost Nothing to Run What should worry defenders most is the cost. > The skill floor for running ransomware has dropped to whatever it costs to run an agent, and if that agent is running on stolen credentials through LLMjacking, the cost to an attacker is close to zero. _Sysdig Threat Research Team_ The agent used stolen credentials to move from one system to the next. Nothing checked whether it was allowed to. That is how one exposed server turned into a full breach. > JadePuffer worked because the agent held real credentials and nothing stood between it and the systems it accessed. That is the exact pattern we build against. An agent should never hold a real password or key. It should start each task with no access and take on only what the person behind it may use. Every step it takes is checked as it happens and recorded once. Then even an agent gone rogue can only use the access it was given for that one task. _Comment from Gil Röder, CPO & Co-Founder_ Source: Sysdig Threat Research Team, "[JADEPUFFER: Agentic ransomware for automated database extortion](https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion)", July 2026. --- # It Doesn't Take a Hacker to Leak Your Data: How to Secure AI Agent Access in the Enterprise [Webinar Recap] _It used to take a hacker to leak your data. That is no longer true. Barbara Teruggi (Allianz Technology) and Johannes Keienburg (Cakewalk) on zero trust for AI agents, default-deny access, and why no identity should complete a full process alone._ By Johannes Keienburg, CEO & Founder Published: 2026-07-06 Source: https://www.cakewalk.security/blog/it-doesnt-take-a-hacker-to-leak-your-data-webinar-recap --- [Video: Webinar recording: It Doesn't Take a Hacker to Leak Your Data](https://watch.getcontrast.io/embed/a0e25a45-9653-4e18-8eab-119cd67c9e23) It used to take a hacker to leak your data. That is no longer true. Connect an AI agent to your applications and it gets static access with broad permissions, often broader than the people who set it up. From that moment, the agent can move, expose, or delete data as part of its normal job. No attacker, no breach, just an agent doing what it was allowed to do. That was the thread running through a recent session between Johannes Keienburg, Founder and CEO at Cakewalk, and Barbara Teruggi, an enterprise security architect who spends her days on exactly this inside some of the world's largest organizations. The two got into what actually changes when agents enter the access picture, why the threat model most teams still use was built for a different problem, and what a secure agentic setup looks like in practice. Machine identities already outnumber humans by roughly 82 to 1 (CyberArk, 2025), and IDC expects more than a billion AI agents in production by 2029. Agents are being wired into enterprise stacks faster than any central team can govern them. The question Barbara kept returning to was not whether to adopt, but how to adopt without handing agents the keys to everything. ## Key Takeaways You do not need a breach to lose data. An agent with broad, static access can leak or delete it as a normal part of doing its job. The everyday risk is quieter than an attack. People put data into agents that should never go near them, and shared agent workspaces expose it to everyone in the room. An AI agent is a [non-human identity](/glossary/non-human-identity) with human capabilities. It has to be governed with [zero trust](/glossary/zero-trust), not with the permissions of the person who introduced it. Default-deny is the right posture. Deny first, allow later, and let the agent ask permission for each job instead of inheriting a standing scope. Credentials belong in a vault, brokered and short-lived, and the agent should never see them. No single identity, human or agent, should be able to complete a full process from start to finish. [Data classification](/glossary/data-classification) is now a daily discipline, not the training you click through once a year. ## The Threat Isn't Only the Attacker Anymore For most of security's history, the threat had a face. Outsider risk, insider risk, the malicious employee. Someone wanted to do you harm, and the job was to keep them out or catch them in the act. Agents break that framing. An agent running autonomously with static access and broad permissions is a risk on its own, before anyone compromises it and before it turns malicious. It can simply decide that deleting a database, or sharing one, is part of the task at hand. Barbara's own summary of what worries her team was the line that reframed the whole conversation. > "We are concerned about attacks, but we are also concerned about how can we be the threat." — Barbara Teruggi, Allianz Technology The point is that a leak no longer requires an intrusion. As she put it, it does not take an attack to leak something accidentally. It can be plain misuse, the organization doing it to itself. Someone from HR drops confidential PII or payroll data into a shared agent workspace, and suddenly everyone in that workspace can read it. The agent was never hacked. It just had access it should never have had. The damage is not limited to data loss either. Point an agent at a code base and it can rewrite or delete parts of it. The [blast radius](/glossary/blast-radius) runs wider than the old [data-exfiltration](/glossary/data-exfiltration) model accounted for, because an agent can act on data where older threats mostly just read it. ## An AI Agent Is a Non-Human Identity With Human Capabilities So what kind of identity is an agent? Barbara's answer was precise, and it is the foundation everything else rests on. An agent is a machine, and it should be treated like one. But it is a machine that acts like a human, which means it can go unchecked and undetected if you are not careful, and it is a machine that can fail. > "It's a non-human identity, but with human capabilities." — Barbara Teruggi, Allianz Technology That blurred boundary is what makes it hard to govern. A traditional non-human identity was strictly deterministic. It did one thing, the same way, every time. An agent has something closer to the freedom of a human. It improvises, and every so often it does something genuinely strange. Two things set it apart from a person, though: it acts at machine speed, and it carries no accountability or liability. You cannot sue an agent. That combination, human-like autonomy with none of the human consequences, is why neither human [access control](/glossary/access-control) nor traditional non-human access control was built to govern it. Which lands you at zero trust. An agent mimics a human, but it should never be mistaken for one, and it should be trusted with nothing by default. ## Why Agents Shouldn't Inherit Human Permissions The most common mistake in agent rollout is the quiet assumption that an agent should get the same permissions as the person who introduced it. Barbara's view on that was blunt: not by a mile. Her analogy was the photo picker on your phone. You can see every image on your device, but when an app asks for access, you hand it a subset, and often a subset of that subset. The same logic applies to agents. Cloud IAM already lets you go granular, defining the exact conditions under which a process accesses a specific piece of information. Agents should be scoped the same way, with [least privilege](/glossary/least-privilege) as the default rather than an afterthought. The human behind the agent still matters as an input. It just isn't the ceiling. A CTO connecting Claude to GitHub should end up with very different entitlements than a junior sales rep trying to wire an agent into engineering environments, where the default answer should be no. The person is a signal that helps shape the scope, not the scope itself. What the agent can touch has to come down to the specific job it is doing, not the identity of whoever set it up. This is the argument for dynamic, job-scoped access. The agent gets what the task needs, and nothing more. ## The Case for Default-Deny Agents If an agent should not inherit human permissions, what is the alternative? Barbara's rule of thumb runs the opposite way to how most teams operate. Deny first, allow later. Build an allow-list of permissions rather than starting from broad access and trying to claw it back. She was candid about why this matters even for non-technical users. Most people are not organized enough to track what their agent can see and do at every moment, and honestly, few of us want to be. It gets messy fast. So rather than granting standing access and hoping for the best, she would rather the agent come back and ask. > "I prefer the agent to ask me, 'May I do this?'" — Barbara Teruggi, Allianz Technology In practice that looks like a user separating what is safe for the agent to touch from what is not. This folder, yes. That folder with the contracts, no. The person stays conscious of what they are putting in each bucket, and the agent works inside those lines. Who draws the lines is a shared responsibility. Leadership decides what is in and out of bounds. Technical and non-technical people translate that into data classifications and policies, then enforce controls on top. But Barbara was honest about the limits of policy on its own. Applying controls to agents can feel like "putting doors in an open field." Some judgment always falls to the end user, which is why the ground rules have to be spelled out in plain language and surfaced at the moment of the decision, not buried in a handbook. A well-designed [policy engine](/glossary/policy-engine) is what turns those rules into enforcement instead of paperwork. ## Keep Agents Away From Production One line was non-negotiable for Barbara: agents doing developer, DevOps, or infrastructure work should be completely separated and segregated from production workloads. Her reasoning drew on how privileged access already works for humans. To reach a sensitive server, a person does not just walk in. They go through a captive portal, hold a specific role, have their session monitored, and often need someone else present to approve what they do. If that is the bar for a human, an autonomous agent should not get a shortcut around it. She pointed to public incidents where an agent held access to production servers and caused damage, and her question was the right one: why did that access exist at all, and if it came from an employee's permissions, why did the employee have them either? She also separated three things that often get lumped together: experimenting with AI in a controlled sandbox, running agents for everyday internal productivity, and putting AI inside one of your own products. Three different levels, three different sets of controls. Lump them together and scope creeps before anyone notices. ## Where Agent Credentials Belong Agent authentication is one of the least solved parts of the stack today. What usually happens is that a human hands over their own credentials to connect an agent to an [MCP](/glossary/model-context-protocol) server or a third-party SaaS system. That static connection is the problem. Barbara's model, drawn from how mature systems already handle secrets, is straightforward. Credentials belong in a vault. A broker retrieves them so the application, or the agent, never sees them directly. Tokens are short-lived and used just in time, then gone. For sensitive operations, you add another relay of authentication, the way a jump server issues a fresh set of keys you never actually see when you reach the end server. > "This credential should be completely transparent to them." — Barbara Teruggi, Allianz Technology The security win is bigger than avoiding credential theft. With no static credential wired into the agent, the agent effectively has to apply for access on each job. That turns credentials into an enforcement point for governance: the agent only carries out the access it genuinely needs, in line with company policy, one task at a time. That is what [credential mediation](/glossary/credential-mediation) does, and it is the difference between least privilege on a slide and least privilege that actually holds. ## No Identity Should Complete a Full Process Alone Near the end, Barbara added a principle that sounds obvious until you sit with it. > "No human or non-human identity should be able to complete a full process. Never." — Barbara Teruggi, Allianz Technology From a breach perspective, the reasoning is airtight. If a single identity can run a process end to end, then automating or compromising that one identity is enough to own the whole thing. Segregation of duties has always been the counter to that, and it applies to agents just as much as to people. She pointed to breaches where attackers rode an agent's broad access into a company's Google Workspace and expanded outward from there. One over-permissioned identity was the whole opening. For agents, this means designing so that no single agent, and no single credential, can carry a sensitive workflow from start to finish without another control in the path. ## Getting Started Without Trying to Be Perfect None of this arrives fully formed, and Barbara was clear that perfection on day one is not the goal. She sees companies spread across a spectrum. Some refuse to touch agents until the fundamentals are in place. Others wire them in straight away and plan to fix the security on the go. Most land somewhere in the middle, picking a set of apps to allow, setting the ground rules, then tightening as they learn. The honest starting point for all of them is uncomfortable: most organizations have not fully brought human access under control yet, and now they are adding autonomous agents on top. Her advice on where to begin came down to a few foundations. Network controls first, both the outer ring and internal segmentation, so exfiltration and infiltration are blocked by configuration and not just by policy. Enterprise accounts for the AI apps in use, with public AI blocked by configuration rather than by a line in a handbook. Constant monitoring down to the process level. And managed settings on the apps themselves, so risky actions can be denied or logged by default. Then there is data classification, which she argued has changed character entirely. It cannot be the annual training you complete and forget. With agents, the boundary moves earlier: the risk starts before an agent accesses anything, at the moment a person decides what to feed it. You have to own your data and know what type you are handling, because that knowledge drives every downstream decision about what an agent should ever touch. Getting there starts with knowing what agents and AI apps are even in your environment, which is where agent and AI discovery comes in. ## Should Agents Ever Run Without a Human? Johannes closed by asking where all of this is heading. Twelve months out, could an agent become the first identity in the chain, getting access directly with no human involved, the fully autonomous workforce everyone keeps predicting? Barbara's answer was a hope more than a forecast: she hopes it does not. And her reasoning is not nostalgia. We have already watched attackers subvert automation flows like GitHub Actions through supply-chain attacks, and agentic systems are nowhere near mature enough to be trusted with that kind of independence. What worries her more is the habit underneath it. We optimize for speed, we ship in less time, and we have been late to secure almost everything we have ever automated. Every round of optimization widens the attack surface, and with agents it does not just widen, it multiplies. Her conclusion was blunt: she does not think we need that level of automation in the first place. For now the human stays in the loop, and not only as a technical control. Legally, the person who introduces an agent is still the one on the hook for what it does. An agent cannot answer for itself, so someone has to, and that is part of why the controls above are not optional. They keep a person accountable for a system that has no accountability of its own. ## Govern Agent Access Before It Leaks The uncomfortable truth from this session is that the biggest agent risk in most stacks is not a future attacker. It is the access already granted, sitting on agents nobody has reviewed, waiting to be used exactly as designed. Stop handing agents your permissions. Cakewalk's AI [Agent Access Management](/glossary/agent-access-management) gives every agent its own identity, default-deny by policy, credentials it never sees, and a full [audit trail](/glossary/audit-trail) of what it actually did. [Get started for free](/control-agent-access) --- # Estonia Wants to Give Every AI Agent Its Own ID _In June 2026 Estonia's prime minister proposed giving every AI agent a national ID code, tied to a responsible operator, with set permissions and an audit trail. It names the right principles. The open question is who checks each action against the limit at runtime._ By Johannes Keienburg, CEO & Founder Published: 2026-06-23 Source: https://www.cakewalk.security/blog/estonia-ai-agent-id --- ## Putting AI Agents on the National Registry In June 2026, Estonia's prime minister, Kristen Michal, endorsed a proposal to give every AI agent its own ID code, recorded in the same national registry that already tracks the country's citizens and companies. Estonia has spent two decades building a digital state, from online voting to its e-Residency program. Giving software a place in the registry is less surprising there than it would be elsewhere. Each agent's code would be tied to the person or organization that deployed it. > To that end, it must be clear who is acting on whose behalf with what rights, and who is ultimately responsible. _Estonian Prime Minister Kristen Michal_ The aim is to make an agent's authority easy to see. An agent's ID would record what it is allowed to do, whether that is reading data, editing documents or making payments, and up to what limit. The framework is also meant to be verifiable and auditable, so an agent's actions can be traced back to a named person or company. ## An Operator, a Limit and a Record The prime minister's office was direct about the problem it wanted to avoid: > The new IDs will help to prevent situations where individuals or organisations are required to grant AI assistants access to all of their rights, services and data. _Office of the Prime Minister of Estonia_ The proposal rests on three principles that anyone governing AI agents would recognize. An agent should answer to a named operator. Its permissions should stay within set limits. What it does should be recorded. The prime minister has asked the Ministry of Economic Affairs to draft the legislation. The technical specifics, including how an agent's permissions and limits would be issued and checked, would be worked out there. > Estonia is naming the right thing: an agent acts for a person, with limited rights, on the record. A driver's license records what you may drive. Staying within the speed limit is checked on the road. An ID works the same way. What stays open is the check on each action as it happens. So we tie every agent to the person it acts for, hold it to the least that person allows and evaluate that access at runtime, on each action it takes through the gateway, with one record of what was allowed, denied or escalated. _Comment from Gil Röder, CPO & Co-Founder_ Source: Office of the Prime Minister of Estonia on AI agent identification, June 2026, as reported by Estonian public broadcaster [ERR](https://news.err.ee/1610060290/estonia-to-become-first-country-to-issue-id-codes-to-ai-agents). --- # Even the NSA Is Warning About the Protocol Connecting AI Agents to Your Stack _In May 2026 the NSA's AI Security Center published security guidance on the Model Context Protocol. It flags missing authentication, capability changes that need no approval and implicit trust between agents._ By Johannes Keienburg, CEO & Founder Published: 2026-06-16 Source: https://www.cakewalk.security/blog/nsa-mcp-security-guidance --- ## MCP's Design Creates the Risk In May 2026, the National Security Agency's Artificial Intelligence Security Center published security guidance dedicated to the [Model Context Protocol](/glossary/model-context-protocol) (MCP), the open standard that connects AI agents to the apps and data they act on. > MCP's rapid proliferation has outpaced the development of its security model. _NSA Artificial Intelligence Security Center_ Although MCP now runs in production across finance, legal and software development, the NSA locates the risk in the protocol's design rather than in any single bug. MCP inverts the usual client-server pattern: its servers can query and sometimes act for the connected client. That inversion, the NSA says, "creates new and largely not well-traced attack paths." The agency found that many implementations skip authentication entirely and that the protocol has no built-in way to exchange [Role-Based Access Control](/glossary/rbac) (RBAC) permissions. Agents trust each other's output without verification. Long-lived context can blend across separate tasks. ## Approved Access Can Escalate Without Review The NSA states its most serious concern plainly: > A previously benign and approved AI service could later access sensitive resources on demand, without triggering any review. _NSA Artificial Intelligence Security Center_ The NSA points to real cases. A GitHub MCP integration granted blanket read and write access across private and public repositories. A separate flaw (tracked as CVE-2025-49596) allowed remote code execution in software used to test [MCP servers](/glossary/mcp-server). The NSA concludes these are not problems to patch at the endpoint level. Securing MCP means "treating the agentic environment as a continuum." ## The NSA's Answer Is Runtime-Scoped Access The NSA's own recommendations point the same way. It tells organizations to draw trust boundaries between agents, plugins, models and users, to put MCP agent processes under [least privilege](/glossary/least-privilege) and to deny any access path they do not need, explicitly and at runtime. Dynamic tool discovery, it adds, should require authorization checks rather than implicit trust. MCP's security never caught up with its adoption. Because the protocol provides little protection of its own, the safeguards fall to whoever runs it. Several of the NSA's recommendations converge on the same idea: keep every agent's access tightly scoped and re-checked as it changes. > The NSA is describing the gap we design against. An agent's access does not stay still: permissions widen, capabilities change and approvals get skipped, none of which the protocol can catch. So instead of trusting access granted once at onboarding, we hold every agent to the least it needs and re-check that access at runtime, on every action it takes. _Comment from Gil Röder, CPO & Co-Founder_ Source: NSA Artificial Intelligence Security Center, "[Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation](https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf)", Cybersecurity Information Sheet, May 2026. --- # How to Adopt AI Agents Securely at Scale: The 4 Zones of Automation [Webinar Summary] _Vercel's breach started with an AI app holding broad, static access. Marco van Hurne (ASML) and Johannes Keienburg (Cakewalk) on the four zones of AI automation, why most zone 3 agent projects fail and why the most dangerous agent in a company is usually a zone 1 agent._ By Johannes Keienburg, CEO & Founder Published: 2026-05-19 Source: https://www.cakewalk.security/blog/how-to-adopt-ai-agents-securely-at-scale-webinar-summary --- [Video: Webinar recording: How to Adopt AI Agents Securely at Scale](https://watch.getcontrast.io/embed/7dd1c6c0-582f-43a0-a58d-d1e0fe0d2dd5) When Vercel disclosed its breach in April, the way in was not a zero-day. It was a third-party AI app one employee had connected to their corporate Google Workspace with broad permissions. The attacker compromised the app, took over the account through the existing [OAuth](/glossary/oauth) grant and pivoted into Vercel's internal systems from there. That is the exact failure mode Marco van Hurne has been describing for years. He calls it Russian roulette with AI agents, and it was the starting point for a working session with Johannes Keienburg, Founder and CEO at Cakewalk, on adopting [AI agents](https://www.cakewalk.security/blog/human-agent-system-working-model-governing-agent-access) securely at scale. Van Hurne has been in machine learning since 2008. He runs the AI factory at ASML, the company that builds the lithography machines the semiconductor industry depends on, and he lectures on process automation in the Netherlands. He recently finished a field study covering 177 companies running autonomous agents in production. The findings are not comforting, and they are very useful. Here is what the session covered. ## Key Takeaways From the Session - Van Hurne's research sorts AI automation work into four zones based on complexity and risk. Zones 1 and 2 form what he calls the identification ceiling, the realistic share of processes today's autonomous agents can take on, currently around 35%. - Roughly 70% of high-value agent projects in zone 3 still fail. Security and compliance are part of why, but the quieter reason is ROI: the human oversight needed to run agents safely in high-risk processes can cost more than the automation saves. - To address the security risks specifically, van Hurne's fix is not a new model or another guardrail. It is to stop treating agents like software and start onboarding them like employees, with scoped credentials, their own identity, defined roles and revocation when the job ends. - Security, permissions, identity and compliance all roll up into trust. Trust is the asset at stake. An agent that sends a bad email from the company's domain has not breached anything technical, but it has spent trust nobody can reclaim. - The most dangerous agent in most companies is not a zone 3 system under heavy supervision. It is a zone 1 agent with broad, static access and no oversight. Governance risk is shaped by access scope, not task complexity. - [Human-in-the-loop](/glossary/human-in-the-loop) oversight degrades fast. After enough approval prompts, people stop reading and start clicking yes. The fix is fewer, smarter escalations, not more. - AI is task-oriented, not job-oriented. Job taxonomy data shows the maximum automation level for any given role is around 70%, not 100%. That changes the headcount conversation. ## The Vercel Pattern, and Why It Keeps Happening The Vercel chain is worth pausing on, because it is going to be the template for a lot of incidents. One employee. One AI app connected to a corporate Google Workspace account with broad scopes. The app's vendor was compromised, and the attacker rode the existing trust relationship straight into the company. No one had to break Vercel's perimeter, because the agent was already inside it with credentials nobody was actively monitoring. Van Hurne's point in the session was that this is not an edge case. It is the median case for how agents get deployed today. Someone connects a useful app, grants it more access than it needs because that is the easy path, and nobody reviews it again. The agent ends up with static, over-scoped access and an identity that looks exactly like a trusted human. > "Five out of six times the agent does its job. The sixth time costs more than the first five saved." - Marco van Hurne, ASML Vercel's customers were the sixth pull. ## The Four Zones of AI Automation Van Hurne's research produced a map, and it was the most useful framework of the session. He sorts processes into four zones by how repeatable, risky and complex they are. Zone 1 is highly repeatable, low-risk, high-frequency work with lots of people in it. Invoice scanning. Email triage. Pulling data out of messages and into a spreadsheet. About 27% of the cases he studied sit here, and if a process is correctly identified as zone 1, the chance of automating it successfully is around 70%. The catch: these are point solutions. They work, but they do not move the needle on company economics. His phrase: zone 1 is the cherry, not the cake. Zone 2 looks like zone 1 with some coordination and a bit of human-in-the-loop. Financial reporting, where an agent collects and organizes data and drafts the PowerPoint, is a good example. Roughly 12% of cases. Together, van Hurne calls zones 1 and 2 the identification ceiling, currently around 35%, which is roughly the share of processes today's autonomous agents can realistically take on. Zone 3 is where the value actually lives, and where the trouble starts. High process complexity, edge cases, compliance risk and explainability requirements. Van Hurne's example is a gross margin review under Sarbanes-Oxley (SOX), the US financial reporting law that requires every step in financial controls to be explainable and auditable. To automate that kind of review, he says, you essentially need one AI checking another. About 30% of processes sit in zone 3, and they are rich in humans, which is exactly why automating them is so attractive. It is also why roughly 70% of projects in this zone fail with current AI. Zone 4 is human judgment. Ethics, legal exposure and high-risk strategic decisions, the things we want humans making on purpose. Publishing a company's annual financial report is van Hurne's example: technically zone 3, but treated as zone 4 because the downside is too big. He also points to the kind of automated decision-making that, done badly, has caused tax authorities to wrongly flag citizens as fraudsters. A small share of processes, and in his view it stays human, partly because the [EU AI Act](/glossary/eu-ai-act) now requires it to. One clarification that helped the room: these zones describe the work being automated, not the AI doing it. ## Why Most Agent Projects Die Above Zone 2 The interesting part is why zone 3 fails, because the reason is usually not what people expect. Yes, there are technical failures. But van Hurne's data points more often at ROI failure. Zone 3 needs observability, explainability and a human-in-the-loop team watching it. If that oversight team has to grow to keep the agents safe, the project stops breaking even. And if it is not breaking even, why automate in the first place? So the project does not fail because the model could not do the task five times out of six. It fails because the sixth time, plus the cost of the people watching for the sixth time, erases the gains. Compliance requirements, deterministic guarantees and the team needed to fix problems are what push otherwise promising projects underwater. This is the part most agent pilots underestimate. The model demo is the cheap 80%. The governance and oversight are the expensive 20% that decides whether the thing survives contact with an auditor. ## Why Trust Is the Umbrella Over Security Toward the end of the session, the conversation moved from security mechanics to what is actually at stake when an agent acts on a company's behalf. Van Hurne's framing was that security and trust are not opposed. Security feeds into trust. So do permissions, identity, access and compliance. They are layers underneath one outcome: whether the company can be trusted to do what it said it would do, and nothing else. His prediction for the next few years sharpens this. As more companies run on similar models and similar processes, the place where they actually compete will narrow. Process advantages will erode. Brand, and the trust that sits underneath it, becomes the durable asset. The moment an agent sends something from a company's domain that it should not have, even without a technical breach, the company has spent trust it cannot get back. His test for whether a process belongs in zone 3 is a good gut check: would you board a plane flown by an agent? He would not. ## The Most Dangerous Agent in Your Stack Is Probably a Zone 1 Agent Keienburg closed the session with a deliberately unfair question for van Hurne: which scares him more, an autonomous zone 1 agent with no oversight wired into company systems, or a well-supervised copilot stuck in a zone 3 process? Van Hurne picked the zone 1 agent without hesitation. The reasoning is the key point of the whole session and the part most companies miss. A zone 1 process is, by definition, low-stakes work. Email triage, data entry, invoice handling. The instinct is to assume the agent doing this work is also low-stakes. That instinct is wrong, because the risk of an agent is shaped by what it can access, not by what it is asked to do. A zone 1 agent connected to Google Workspace with broad OAuth scopes is one compromised app away from being the Vercel pattern, regardless of how innocuous its day job is. Keienburg pushed the same point from another angle: even if the agent does exactly what it is supposed to do, the moment it can reach sensitive systems on a static, over-scoped credential, the security and trust problem already exists. You do not need a hallucination or a malicious prompt to get burned. You just need an unsupervised agent with access that is broader than its task. This is the practical implication for any security or IT team running agents today: stop sorting governance priority by task complexity, and start sorting it by access scope. Most agent governance gaps live in zone 1, not zone 3. ## The Agents-as-Employees Fix When Keienburg asked how van Hurne actually handles this operationally, the answer was straightforward. He treats agents like employees. A process is a collection of tasks. AI is displacing tasks, not jobs. So an agent that performs tasks should be onboarded the way a person is: given a role, the rights that role needs, its own identity and an offboarding when the work is done. He does not let an agent read his inbox as him. He gives it guest access with its own credentials and its own authority level, so when it acts, it acts as itself, not as him. That distinction matters more than it sounds. It is the difference between an agent inheriting a human's entire footprint and an agent having a scoped identity that can be reasoned about, reviewed and revoked. Onboarding. Roles and rights. Review. Revocation. Revocation in particular is the step most companies forget, and it is the one that would have contained the Vercel incident. ## The Consultant Analogy Keienburg offered an analogy during the conversation that van Hurne agreed with. If a company hires an outside consultant for a specific job, it does not hand them static access to every room in the building, broad permissions to take data out and the ability to modify systems they have no business touching. The access is scoped to the work. Yet that is exactly how most agent credentials are issued today. The agent gets a broad [API key](/glossary/api-key) or OAuth grant. The app sees valid credentials and allows the request. Nothing checks whether the specific action the agent is taking right now is inside the scope of what it was actually asked to do. An agent is not a human identity. It is also not the kind of [non-human identity](/glossary/non-human-identity) that has been managed for the last decade, because those had far less autonomy. It is a new category, and it needs access tied to the job in front of it, not to whoever signed the agreement. ## Authorization Fatigue, and Why Human-in-the-Loop Breaks Everyone reaches for human-in-the-loop as the safety net. The data, and a lot of personal experience in the room, says it degrades fast. Keienburg flagged decision fatigue from his own use of coding agents. Early on, he read every proposed action carefully. A few weeks in, he found himself clicking yes, yes, yes, yes to get the work done. At machine speed, that point arrives quickly. When an agent escalates dozens of decisions an hour, the prompts become noise, people auto-approve and the oversight becomes theater. Some attack patterns exploit this directly, slipping past the human who has stopped reading. The answer is not more approvals. It is fewer, smarter ones. Only surface the genuinely ambiguous cases and let policy handle the rest. That requires context, not just a yes/no gate. ## The Observability Gap Nobody Has Solved Yet This was the part where van Hurne got animated, because it is unsolved and he had to build it himself. In his factory at ASML, a process operator sits in front of a large screen watching processes run, pulling telemetry from different systems, tying it into a flow with red and green lights and intervening when something goes wrong on security, identity, access, operations or compliance. It is the SIEM idea, the Splunk-style dashboard, but for agent operations. It does not exist as a product. He duct-taped it together because the market has not built it. His words, roughly: anyone building this, call me. He compared the role to a chemical plant operator. In a plant, trained chemists watch the process and know when to open a flare or close a vent. The new agent-operations roles are the same idea applied to software. They require real domain expertise, and the job boards in the US and the Emirates are already paying well for them. ## Will AI Take the Jobs? What 177 Companies Actually Show The session did not skip the obvious question. Van Hurne is, by his own description, one of the people reducing FTE, although as a European company ASML re-skills rather than lays off. But his read on the numbers is more grounded than the headlines. The World Economic Forum projected 83 million jobs gone by 2030. Goldman Sachs floated 300 million. Anthropic's CEO said 50% of white-collar jobs and 10 to 20% unemployment. In the same period, the International Labour Organization put displacement at 2.3%, with the rest augmented. A 2026 MIT study looking at 22,000 jobs landed where van Hurne's own research did: AI is task-oriented, not job-oriented. He built a method to calculate this. Job taxonomies like O*NET in the US and ESCO in Europe describe jobs as sets of standardized tasks. Because a process is a collection of tasks, and a job is a collection of tasks, the automation zones map onto roles. The result: the maximum automation level for any given job lands around 70%, not 100%. The job still exists. What changes is how many people are needed in it, and which roles get hit hardest. Junior, zone-1-heavy work is the most exposed. Keienburg offered a slightly different lens during the session: there is also a world where the productivity bar for a normal worker rises through AI rather than headcount falling. Either way, the practical conclusion is the same. Agents are coworkers that have to be managed, not software that can be installed and forgotten. ## What Security and IT Teams Should Do Now A few concrete starting points from the session. Inventory the agents. Most organizations cannot say which agents are deployed, what credentials they hold or what scopes those credentials carry. Long-lived human credentials with broad access, attached to an agent that nobody is watching, is the Vercel setup. Start there. Give every agent its own identity. Not a borrowed human login. A scoped identity with the rights the task needs, that can be reviewed and revoked. If an agent cannot be cleanly revoked, it is not really under control. Treat tool execution as the security boundary. The risky surface is not what the model says. It is what it does through its tools. That is where irreversible actions happen. Prioritize governance by access scope, not task complexity. A zone 1 agent with broad scopes is a higher risk than a zone 3 agent under tight oversight. Most governance gaps live in the assumed-safe places. Make human oversight selective. Approving everything trains people to approve nothing. Escalate the ambiguous cases, let policy handle the rest and design for that from the start. Build the evidence trail before it is needed. The observability layer auditors will ask for under DORA, [ISO 27001](/glossary/iso-27001) and [SOC 2](/glossary/soc-2) is hard to reconstruct after an incident. Capture the context now. ## FAQ **What Are the Four Zones of AI Automation?** A framework from Marco van Hurne's research on 177 companies. Zone 1 is highly repeatable, low-risk work (about 27% of cases, around 70% automation success). Zone 2 adds coordination and light human-in-the-loop (about 12%). Together they form the realistic automation ceiling, around 35%. Zone 3 is complex, high-risk, compliance-heavy work (about 30%) where roughly 70% of projects fail. Zone 4 is human judgment and ethics, which stays human. **Why Do Most AI Agent Projects Fail?** Above zone 2, failure is often economic rather than technical. The observability, explainability and human oversight needed to run agents safely in high-risk processes can cost more than the automation saves, so the project never breaks even. **What Does "Treat AI Agents Like Employees" Mean?** Onboard each agent with a defined role, only the rights that role needs, its own identity rather than a borrowed human login, ongoing review and revocation when the work ends. It is the opposite of handing an agent a broad, static credential and never looking again. **How Does This Relate to the Vercel Breach?** The Vercel incident started with an AI app connected to a corporate account with broad permissions and no real review. Scoped credentials, a separate identity and revocation are exactly the controls that would have limited that [blast radius](/glossary/blast-radius). ## Join the Agent Access Management Waitlist If the Vercel pattern and the agents-as-employees fix sound like problems the company already has, that is what [Cakewalk's Agent Access Management](https://www.cakewalk.security/agent-access-management) is built for. We help IT and security teams govern access for AI agents and human identities in one place, with scoped, policy-first access and an [audit trail](/glossary/audit-trail) for every action. Be the first to control AI agent access. [Get started now](https://www.cakewalk.security/control-agent-access). --- # Human → Agent → System: A Working Model for Governing Agent Access _How a line on our 2023 roadmap became security’s biggest unsolved problem and led to the access layer we are now building._ By Johannes (with Gil) --- ## San Francisco, May 2026: AI Agents Will Be the Biggest Revolution in Human History. But… If you want to understand to what extent the world is changing these days, you have to look at the billboards in San Francisco: AI agents everywhere. Agents for sales, agents for engineers, agents for everything. Every ad, every meetup, every coffee chat: same theme. Autonomous agents are one of the biggest revolutions of our time. To make this revolution safe, we have to get agent access governance right. The question is still unsolved: what AI agents can do, who they act for and which systems they reach. Why? Because without enough agent access governance, breaches are already happening. --- ## The Vercel Breach: From a Compromised Laptop to a $2 Million Sale of Stolen Data On April 19, Vercel disclosed a breach. The chain began months earlier. Context.ai is an enterprise AI platform with a Google Workspace integration. Its AI Office Suite builds agents trained on company-specific knowledge. A Vercel employee signed up for it using their Google Workspace account and granted Context.ai "Allow All" OAuth permissions. Researchers later traced the chain back to February, when an infostealer compromised a Context.ai employee's laptop and opened a path into the OAuth grants Context.ai held for its customers.[^2] The attacker used the Vercel grant to walk into Vercel's Workspace, then into the internal environment. They exfiltrated what Vercel called "non-sensitive" environment variables: API keys, tokens, database credentials and signing keys.[^1] The attacker listed the data for sale on the criminal forum BreachForums for $2 million.[^2] Vercel's CEO described the attackers as "highly sophisticated and, I strongly suspect, significantly accelerated by AI."[^4] The breach moved through four links: a compromised vendor laptop, a vendor with stored OAuth grants, a Vercel-issued credential and an enterprise Workspace. None of them had been reviewed in living memory or required anyone to be in the loop at the moment they were used. The layer that would govern this kind of chain is still scattered across the industry. --- ## The Vercel Pattern Repeats Across the Industry Across these breaches, the same shape returns. The Salesloft Drift breach in August 2025 reached more than 700 organizations, including Cloudflare, Zscaler and Palo Alto Networks.[^3] Context.ai is the latest in the line. The mechanics are familiar by now: OAuth grants that accumulate faster than anyone reviews them, consent screens that bundle every future call into a single yes, audit trails that name the human at signup but not the agent at runtime. The trust model under OAuth was built for a single-vendor application acting on a user's behalf. Once the grant is given, almost nothing watches what the vendor does with it. In two earlier pieces, we mapped [why agentic access is the new frontier in security](https://www.cakewalk.security/blog/the-new-frontier-in-identity-security-is-ai-agent-access) and [the current protocols and enforcement architectures to tackle this](https://www.cakewalk.security/blog/governing-the-new-frontier-the-missing-layer-for-agent-access). Every solution we surveyed closes one edge of the chain, sometimes two, while none closes all three. That gap is the one we keep running into. The shape it leaves exposed is the one we have been preparing Cakewalk to govern: _Human → Agent → System_. --- ## The Three-Actor Topology: From Machine-to-Machine to Human → Agent → System When we started Cakewalk back in 2023, our mission was to build Access Management that worked across the entire workforce: simple enough for any employee to use and yet powerful enough for IT and security teams to rely on. Early on, our roadmap included what we called "machine-to-machine access" back then: one corner of what the industry calls non-human identity (NHI). The phrase fit a small and well-behaved set of workloads at the time: a handful of service accounts, a few CI tokens, the occasional cron job that needed to talk to a database without a person in the loop. For those workloads, identity took the form of an OAuth grant or an API key issued to a piece of software, with scope set at deploy and behaviour written into the code ahead of time. Two actors and a credential between them: a Machine → System model that worked because the credential's scope was small and predictable. By 2026, AI agents inherited the same credentials as machine-to-machine access but with none of the predictability. The reason is simple, in that traditional non-human identities do not act autonomously, while autonomy is exactly what makes access governance crucial. An agent therefore needs runtime primitives similar to those a human needs: who delegated to it, which system it is acting against and with what authority. The new shape that emerged with agents is a triangle with three actors at its corners: a delegating human, an acting agent and a target system. Every agent inherits its right to act from the human who delegated to it. Every action that agent takes is directed at the system with its own constraints. Every access decision is now defined across all three positions at once. Each major failure of the past year sits on one of these three edges of the triangle. Accountability rests on the human edge. Without the human kept in the chain at the moment of access, accountability disappears. Every action becomes anonymous, attached to a credential rather than a person. Compliance frameworks that assume a human at the end of the chain (e.g., SOC 2, NIS2) stop working in any auditable sense. So does anyone trying to reconstruct what happened after the fact. The Vercel shape comes from the agent edge of the triangle. When the agent itself is invisible to the layer that would govern it, what is left between the human and the system is a static OAuth grant exercised at the agent's discretion, with no enforcement in the path. The grant might have been reasonable on the day it was issued. Whether it is still reasonable today, used by an agent with new capabilities and inside a context the original grant did not anticipate, is a question the layer is not equipped to answer. The system edge is the one most often dropped from the conversation, on the assumption that the agent's context already matches the system it is calling. There is no way to confirm that the agent's context matches reality. The same agent action that is safe against a sandbox is destructive against production. Without the target system in the picture, no policy can be evaluated against what the call will do. The fact that the call was made is all that registers. The breaches we studied this year, including Vercel and Salesloft Drift, fit this picture. Each one is a triangle with one edge missing. --- ## How We Are Building Agent Access Management We are building the access layer that closes all three sides at once. We call it Agent Access Management at Cakewalk. The difference from any earlier sketch is that the human is now inside the access decision, not just in the audit trail. The credential is where the Vercel chain breaks down first. In [Cakewalk's gateway](https://www.cakewalk.security/blog/governing-the-new-frontier-the-missing-layer-for-agent-access#how-cakewalk-turns-a-gateway-into-governance), every token exists for the duration of one session: permissions are injected the first time the agent needs them and revoked the moment the session ends. Cakewalk keeps the tokens in its own vault, separate from the agent. The agent's context window is its most exploitable surface, because agents are built to read untrusted input and a single prompt injection can pull anything stored there out into the open. Keeping the tokens in a separate vault means even a compromised agent has no tokens to leak. One gateway sits between the agent and every system it reaches, replacing dozens of unmanaged grants and removing the Agent → System surface the Salesloft/Context.ai pattern depends on. What happens at each call is the next decision. Where the OAuth model presents the user with one decision at signup ("Allow") that covers every subsequent call the application makes, our gateway evaluates each individual tool call as it is made. The gateway reads three inputs at every evaluation: the action being requested, the delegating human and the target system. The result is a deterministic, reproducible policy decision specific to that combination, meaning the same input produces the same answer and that answer can be replayed at any later time. All three edges of the triangle are closed at the same evaluation, because it is the only point in the chain where all three are visible at once. The delegating human is part of every decision, not just the audit trail. Every action an agent takes is tied back, in the audit trail and in the policy decision itself, to the human who delegated to it. When that human's role or department changes, every agent acting on their behalf inherits the change instantly. The audit trail is built around the delegating human first and the credential second. That inverts OAuth's static grant model and makes "who owns this agent" answerable at runtime. The Human → Agent accountability that disappears under the static-grant model is restored. --- ## From the Defining Question to the Central Layer We Are Building Three years ago we put machine-to-machine access on the Cakewalk roadmap. That same line is now the defining question in enterprise security and the Human → Agent → System layer is what we are building to answer it. The companies that deploy agents safely over the next several years will treat agent access as infrastructure, the way they already treat identity and networking. And that is what's needed to turn billboard talk into global reality, securely. --- ## References [^1]: Vercel (2026). _April 2026 Security Incident_. https://vercel.com/kb/bulletin/vercel-april-2026-security-incident [^2]: Tom's Hardware (2026). _Vercel breached after employee grants AI tool unrestricted access to Google Workspace_. https://www.tomshardware.com/tech-industry/cyber-security/vercel-breached-after-employee-grants-ai-tool-unrestricted-access-to-google-workspace [^3]: Google Cloud / Mandiant (2025). _Data theft from Salesforce instances via Salesloft Drift_. https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift [^4]: Rauch (2026). _Statement on Vercel security incident_. https://x.com/rauchg/status/2045995362499076169 --- # AI Agent Access Control for Regulated Industries: What EU Auditors Are Already Asking [Webinar Recap] _Your auditor is already getting ready to ask about AI agents. If your SOC 2, ISO 27001, or DORA audit lands in 2026, you can assume agent access will be in scope. Julie Gibelin (Talon.One) and Johannes Keienburg (Cakewalk) on what changes when agents enter the access picture._ By Johannes Keienburg, CEO & Founder Published: 2026-04-21 Source: https://www.cakewalk.security/blog/ai-agent-access-control-regulated-industries-eu-auditors-webinar --- [Video: AI Agent Access Control for Regulated Industries: What EU Auditors Are Already Asking [Webinar Recap]](https://youtu.be/2qJ5C-qKNcg?is=da0rutVwdJma9Jev) Your auditor is already getting ready to ask about AI agents. If your [SOC 2](/glossary/soc-2), [ISO 27001](/glossary/iso-27001), or DORA audit lands in 2026, you can assume agent access will be in scope, even if the framework itself hasn't caught up yet. That was the clearest takeaway from a recent session between Johannes Keienburg, Founder and CEO at Cakewalk, and Julie Gibelin, Senior Information Security Officer at Talon.One. Julie spent years building access governance at N26, one of Europe's most scrutinized fintechs. Now she is doing it again at Talon.One, this time with AI agents actively in play across the stack. The conversation dug into what actually changes when agents enter the access picture, why most compliance frameworks were not designed for this, and how to prepare for your next audit without pretending the tooling landscape is further along than it is. ## Key takeaways - EU auditors will ask about agentic access under DORA, [HIPAA](/glossary/hipaa), and ISO 27001 within your next audit cycle. - Current compliance frameworks cannot catch runtime dependencies. The checkbox model is breaking, and the recent fake SOC 2 reports scandal is one early signal of what that looks like. - Most companies still cannot reliably produce [access control](/glossary/access-control) evidence for human users. Agent access makes that gap 10x wider. - Three properties compound each other: static long-lived credentials, autonomous behavior at machine speed, and catch-all broad permissions. - [Human-in-the-loop](/glossary/human-in-the-loop) breaks down in practice because of decision fatigue. People stop reading the prompts after a while. - Start with toxic combinations and security design principles, not granular permission policies (they can come at a later stage). Define what a role should never do before you define what it can. ## Agent access is already a bigger problem than human access Johannes opened with a forced choice. What is worse: walking into your next audit with no access control evidence for your employees, or knowing your teams are wiring AI agents into production systems without any oversight at all? Julie did not hesitate. Option two. Agent adoption is already widespread in regulated industries, fintechs included, and regulators are scrutinizing it. The tooling to monitor agents at runtime is not really there yet, so for now, teams are stuck with manual configs and manual access decisions to keep any governance layer in place. Her point was clear: companies have not fully solved human access governance. Asking them to bolt on agent governance without changing the model is setting them up to fail on both. > "You can be very good at the paperwork, but that doesn't mean you're necessarily very good at security." — Julie Gibelin, Talon.One ## Why agent access is not just a new flavor of IAM Julie broke down why agents are not just another identity type. The same pattern kept showing up across her answers: agents act in runtime, across chains of dependencies, and change context while they are doing it. You can control whether your agent has access to a specific resource. You cannot control the whole chain. Once the agent is running and has an objective to hit, it will take whatever path works. That is not malicious. That is the point of an agent. But it does mean predicting the [blast radius](/glossary/blast-radius) is hard, especially on a developer's laptop where the agent is also "negotiating" with the terminal, the kernel, and local files. There are three compounding properties that make this different. ### Static long-lived access When a team member connects Claude or any other agent to GitHub, the CRM, or an HR system, they approve it once and move on. The access stays. Nobody rotates it. Nobody revokes it. The static credential was designed for a machine identity, not for something that can improvise. ### Autonomy at machine speed Behind that static credential is an agent that only unlocks its value when it has the autonomy to act. An agent doing what it was asked will happily go down the wrong path, share data, or delete a table it decided was not needed. Again: not malicious, just trying to complete the task. ### **Catch-all permissions** Connect Claude to GitHub via [MCP](/glossary/model-context-protocol) and the agent inherits the full tool surface. No job-specific scope. No differentiation between a CTO's use case and a sales team's use case. Static plus autonomous plus broad is the combination that breaks conventional access models. A fourth property is worth naming alongside these: most agent deployments today produce no accessible [audit trail](/glossary/audit-trail) on the client side. If the action happened at 3am via MCP and nothing wrote it down, good luck reconstructing the decision for your auditor. ## Human-in-the-loop works, until it doesn't The obvious answer is to keep a human in the approval loop. Julie has tried this. It works as a guardrail, and it is probably the best thing most teams can do today. But there is a psychological tax that is easy to underestimate. When you are excited about an agent solving a real problem, you approve faster. You stop reading the details. You say yes to the terminal access, yes to the file system, yes to the API call. Not every user has the knowledge to make those calls correctly in the first place, and even the ones who do get fatigued. Johannes pointed to his own behavior with coding agents. Early on, every prompt gets scrutiny. Three weeks in, it is yes, yes, yes. The fix is not to remove humans from the loop. It is to stop asking them to rubber-stamp the routine stuff and save their attention for the cases the system genuinely cannot resolve. ## Start with toxic combinations, not policies When Johannes asked how Julie would build access governance from scratch in a company that treated compliance as a priority, her answer was not "buy a tool." It was "define your toxic combinations first." This sits upstream of any specific policy. Before you get granular on permission schemes, you write down the things a role should never be able to do. CEOs do not get access to production. That one is easy (CEOs might disagree). But there are subtler combinations across tools that, when stacked, create real risk. Julie floated a wish here: she would love a tool that could derive contextual, company-specific security design principles automatically. [Attribute-based access control](/glossary/abac), but driven by the context of what the company actually does. A fintech has different toxic combinations than a content startup. Nobody is fully solving that yet. ## What Talon.One is actually doing Talon.One is not regulated the way a bank is, but it supports large, demanding enterprise customers. Julie's approach has been iterative by design. Rather than green-lighting every AI tool at once, her team picked a provider, started connecting internal resources (not production, not yet), and built connectors one at a time against tested user needs. Every agent creation still goes through central review. Configs get checked. Guidelines exist and are enforced. She also talked about a simple but useful experiment: running an internal agent to scan company resources for exposed secrets, [API keys](/glossary/api-key), credentials, and PII. When it finds something, she takes it back to the relevant team and asks the obvious question: do we actually need this published? It has already reduced the surface of exposed sensitive data in public and internal resources. > "You can have all the sophisticated tools in the universe. It will never replace the human factor." — Julie Gibelin, Talon.One The human factor kept coming up. Security leaders who rely only on centralized policy will miss what is actually happening in product and engineering. You have to be in the RFCs. You have to be on the team channels. In regulated tech specifically, you cannot block your teams from using AI. Market pressure will not let you. ## What EU auditors will ask about agentic access Julie was direct here. Talon.One has a SOC 2 audit coming up. She already knows AI will be in scope. She does not yet know how granular auditors will get. Nobody does yet. But the direction is clear: - Some form of AI governance has to be in place. - You need an inventory of agents. How many exist, what they are, where they sit. - You need logs you can retrieve and show. Not eventually. - And: You need a plan how to manage this going forward! This maps to what DORA, HIPAA, and ISO 27001 already require in principle, even if not by name. Granular access controls, auditability, and evidence that the controls are enforced. Agents inherit all of those requirements the moment they touch anything regulated. ## Europe's AI regulation: the honest take from a security practitioner Johannes asked Julie whether Europe's approach to AI regulation was on the right track. Her answer was nuanced in a way worth capturing properly. She supports regulating and enforcing security. The question is not whether there is too much or too little compliance. It is the how. DORA, in her view, is an important piece, but the people writing these frameworks often lack hands-on operational experience. That creates friction with the innovation and speed European tech companies need to stay competitive. She has lived this from inside. In her earlier role in a second line of defense control function, she was too far from the teams actually building things. The controls were not reflective of operational reality. They were checkboxes derived from frameworks written a long time ago. Her prescription: get practitioners into the room when regulation is being written. Modernise the frameworks. Be willing to throw some of them out and start again from the operational realities of how modern companies run. Compliance needs to shift toward by-design, embedded in the systems themselves, not extracted manually by a team every audit cycle. Johannes added a harder edge to this. Europe arguably has more AI regulation than AI right now. And the checkbox approach creates its own failure mode. The recent case of a compliance company selling fake SOC 2 reports, despite having millions in funding, is what you get when compliance and security become separate disciplines (and when founders are reckless). If you are only asked "do you have an access control policy?" and not "show me what your agents actually have access to right now," the policy is just paper. Julie agreed. Incentivising companies to produce mountains of paperwork pulls resources away from actual security work. AI, ironically, makes the paperwork part trivial. Ask a modern model to do a DORA gap analysis and it will do it, and it will be pretty good. Which only makes the case stronger that auditors need to start asking about the things AI cannot fake: live dependencies, runtime behavior, actual logs. ## How to prepare for your next audit A few concrete actions for security and compliance teams in regulated EU environments, drawn from the session: 1. **Inventory your agents.** Who introduced them, what they are connected to, which credentials they are using. Most teams have no clean list. This is the single biggest gap between current reality and what an auditor will ask for. 2. **Start with toxic combinations.** Before you debate permission schemes, write down what roles and agents should never be able to do. This becomes the frame for every policy decision downstream. 3. **Treat tool execution as the security boundary.** Focusing on what the model says misses the point. The risk is what it does through its tools. 4. **Capture logs now, even if imperfect.** Something is better than nothing. An agent action without a log is an incident you cannot investigate. 5. **Get closer to the builders.** Security leaders who sit in central teams miss the real risk. Be in the product RFCs. Be on the dev channels. Educate, do not block. ## Govern agent access before auditors start asking If your next SOC 2, ISO 27001, or DORA audit includes questions about AI agent access, you want to be showing evidence, not explaining why you do not have it. Cakewalk's AI [Agent Access Management](/glossary/agent-access-management) is built for this. Dynamic, job-scoped access for AI agents. Real-time policy enforcement. A complete audit trail for every agent action. Built for security teams operating in EU regulated environments. --- # Runtime Governance: The Missing Layer for Agent Access _Five industry responses are shaping agent identity and authentication. None governs what agents do at runtime. This article maps the gap and the four architectures that could fill it._ By Gil Röder, CPO & Co-Founder Published: 2026-04-15 Source: https://www.cakewalk.security/blog/governing-the-new-frontier-the-missing-layer-for-agent-access --- ## Agent Identity Is Not Enough In December 2025, an AWS engineer asked Amazon's Kiro agent to fix a bug in AWS Cost Explorer. The agent decided the cleanest path was to delete the production environment and rebuild it from scratch. It did. AWS Cost Explorer went down for thirteen hours.[[1]](https://www.aboutamazon.com/news/aws/aws-service-outage-ai-bot-kiro) The agent had not broken in. A human operator had granted it their own access level, which turned out to be broader than anyone realized. Amazon's two-person approval process did not apply to AI agents in practice. Nothing evaluated the deletion before it happened. Amazon's post-mortem called it _"misconfigured _[_access controls_](/glossary/access-control)_, not AI."_ Both things are true. And both miss the bigger point: when controls are misconfigured, nothing catches it at runtime. The agent does what its permissions allow, at machine speed, with no second pair of eyes. This pattern is not specific to Kiro. Every AI agent inherits the permissions of the human who delegates to it. Those permissions are wide at setup and accumulate over time. In [_The New Frontier in Identity Security: AI Agent Access_](/blog/the-new-frontier-in-identity-security-is-ai-agent-access), we laid out why that is the default shape of agent access today. The industry has been responding. Over the past year, five protocols have emerged to give agents a place in enterprise identity. Four enforcement architectures have emerged above them. Stopping the next Kiro needs more than identity. It needs a decision on every tool call before it happens, traceable back to the human who delegated. ### The five protocols aimed at agent identity [Model Context Protocol](/glossary/model-context-protocol) (MCP) gives agents a universal way to call tools. A tool is a single, named action an agent can take, like `send_email`, `query_database` or `delete_file`. An app (GitHub, Slack, Salesforce) exposes its capabilities as tools through an [MCP server](/glossary/mcp-server). One app, many tools. MCP defines how the call travels, but not who may make it or under what conditions. Five efforts now address that gap. They come from different parts of the stack: two standards bodies (IETF, OWASP), one protocol author (Google) and one identity vendor (Okta). **1. **[**A2A**](/glossary/a2a-agent-to-agent-protocol)**, the Agent-to-Agent protocol **(Google → Linux Foundation).** **Google describes A2A as “designed to support enterprise-grade authentication and authorization, with parity to OpenAPI's authentication schemes.”[[2]](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) In practice, A2A lets one agent delegate a task to another. The requesting agent reads the target's Agent Card, a JSON file listing what the target can do. It then sends the work as a structured task object. The target processes the task and updates its state as it goes: `submitted` on arrival, `working` during processing, `auth-required` when an action needs permission. At this point execution pauses. Because A2A specifies no authorizer, the protocol marks the pause without defining who should answer it. **2. IETF Agent Auth** (AWS, Zscaler, Ping Identity). A resource server is the app or service an agent is trying to access. This draft defines how an agent identifies itself to that server when acting on a user's behalf. Standard [OAuth](/glossary/oauth) issues a token that names only the user. This draft binds two identities into the same token: the agent goes into the `client_id` claim and the delegating user into the `sub` claim. A resource server reads both and authorizes the request against the pair, not the user alone. To do this, the draft composes existing standards rather than inventing new ones. Its authors acknowledge the limit: “additional specification or design work may be needed to define how out-of-band interactions with the User occur at different stages of execution.”[[3]](https://www.ietf.org/archive/id/draft-klrc-aiagent-auth-00.html) The framework binds the agent's identity at token issuance but defers the runtime authorization question to future specifications. **3. AAuth** (IETF Draft). AAuth extends OAuth 2.1 with a `reason` parameter. The specification defines it as a “concise, human-readable explanation provided by the agent.”[[4]](https://datatracker.ietf.org/doc/html/draft-rosenberg-oauth-aauth-01) The authorization server must echo this reason verbatim and display it to the user. It does not verify that the reason is accurate, proportionate or consistent with policy. Any claim passes. Once the token is issued, AAuth has no further role. It grants access once, at the start of a session. What the agent does with that access is not governed by the framework. AAuth addresses transparency at first access. It does not address control during execution. **4. **[**SCIM**](/glossary/scim)** Agent Extension** (Okta). SCIM is an existing standard for provisioning and managing user accounts across enterprise systems. Okta's IETF draft extends it with two new resource types, `Agent` and `AgenticApplication`, that register AI agents as directory objects alongside human users. An agent with a SCIM entry has an official identity in the system: a name, an ID, a lifecycle that can be managed and revoked. The extension is designed as complementary infrastructure, “intended to provide greater interoperability… while reducing the responsibilities assumed by… new protocols for agents.”[[5]](https://www.ietf.org/archive/id/draft-abbey-scim-agent-extension-00.html) It manages whether an agent exists, but not what the agent does at runtime. **5. OWASP ANS**. OWASP describes the Agent Name Service as “a framework for secure discovery and registration of AI agents in multi-agent systems.”[[6]](https://genai.owasp.org/resource/agent-name-service-ans-for-secure-al-agent-discovery-v1-0/) ANS functions like DNS for agents: an agent registers by publishing an Agent Card that contains its name, capabilities and endpoint. Other systems query the registry to confirm the agent exists and is who it claims to be. The framework resolves the question of identity. It does not resolve the question of authorization. A verified agent is not a permitted agent. All five efforts address questions that arise before an agent acts: is it real, can it prove its identity, is it registered. These are prerequisites for execution, not constraints on it. Once resolved, the agent holds a valid identity, proven credentials and a place in the directory. Nothing in that stack evaluates what happens next. The missing question is runtime governance: should this agent perform this specific action right now, given the data it has already accessed and the tools it has already called? "Who" and "how" have answers. "Should" is still the missing question. **Definition: Runtime governance.** A decision evaluated on every tool call before it executes. The decision considers the action, the human behind the agent and the target system. Each outcome traces back to a person. ## Four Architectures for Runtime Governance The moment before Kiro executed the delete: the agent has the request formed, the token ready, the production environment in reach. Identity is confirmed. Intent is generated. Every Section 1 protocol has done its job. What is missing is the single decision in between: should this specific action go through, or not? That decision has to sit somewhere in the stack, and where it sits is constrained by what the security team actually controls. Three things determine the options. Does the team run the infrastructure the agent executes on, or is it a cloud service like ChatGPT, Claude or Microsoft Copilot? Does the agent platform expose hooks the team can instrument? Does the downstream app accept external policy enforcement? Different answers rule out different architectures. The market has converged on four enforcement architectures. Each places a checkpoint at a different layer: in the network, inside the agent's runtime, at the operating system or inside the downstream app. The [_Autonomous Action Runtime Management_](https://arxiv.org/abs/2602.09433) specification (arXiv, February 2026)[[7]](https://arxiv.org/abs/2602.09433) formalizes the same four patterns. Here is what each one does, where it sits and what it trades away: ### Protocol gateway A protocol gateway places the enforcement boundary in the network, between the agent and the tools it connects to. When an agent is about to send an email, query a database or delete a file, the request passes through the gateway first. The gateway intercepts every tool call, checks it against policy and decides: allow, deny, escalate to a human or wait for more context. Because the gateway speaks the same protocol the agent already uses (MCP, A2A or any standard protocol), nothing changes on either side. The agent does not know the gateway is there. The downstream app does not know either. The gateway remembers everything the agent has done in a session: which tools it called, what data it accessed, what parameters it used and what the tools returned. The gateway evaluates each new action against the entire chain, not in isolation. An agent with permission to query a customer database and permission to send emails can do both individually. But if it reads customer records and then sends an email to an external address, a protocol gateway recognizes the composition attack: [data exfiltration](/glossary/data-exfiltration). The composition violates policy in a way that neither action reveals on its own. The tradeoff is visibility at the boundary. The gateway sees every action that passes through the protocol. It cannot see the agent's internal reasoning, its memory or actions that bypass the protocol (local file reads, shell commands, in-memory operations). It controls the border between the agent and its tools, not what happens inside the agent. ### SDK instrumentation SDK Instrumentation places governance checkpoints inside the agent's own runtime. Before the agent reads a customer record, a hook (an extension point the platform exposes) fires inside the runtime. The SDK checks it against policy and records what happened. Because it operates inside the agent, it has the deepest visibility of any architecture. It sees the original user request, the reasoning chain, prior actions in the session and what data the agent has already accessed. The limitation: every agent framework needs its own integration. There is no universal SDK. If you run five different agent frameworks, you need five separate integrations. And because the SDK runs inside the same program as the agent, it can be bypassed. A compromised agent can call tools directly without passing through the hooks. A protocol gateway, by contrast, runs outside the agent as a separate service, and the agent has no path to its tools except through it. The SDK is only as trustworthy as the agent it governs. ### Kernel-level monitoring The third architecture operates below the application, at the operating system itself. Every action an agent takes on a machine, whether it opens a network connection, writes a file or starts a process, passes through the kernel. Monitoring at this level means intercepting those system calls before they execute. The kernel can allow the call, block it or log it for review. Tools like Falco and Sysdig already do this for general security. The same approach applies to agent governance. The tradeoff is visibility without context. The kernel knows the agent opened a network connection, but not that it was trying to delete a production database or whether the actor who triggered it had permission to do so. Kernel-level monitoring catches forbidden actions like connections to known malicious endpoints, but it cannot replace a governance layer that understands what the agent is doing and why.[[7]](https://arxiv.org/abs/2602.09433) ### Vendor app integration The fourth approach pushes enforcement into the downstream apps themselves. Each app vendor (GitHub, Slack, Salesforce) implements its own governance hooks. Before the agent calls any app, the [identity provider](/glossary/identity-provider) (IdP) authenticates it and issues a scoped token. What happens after that depends entirely on what the app vendor chose to enforce. Its appeal is independence from the agent side of the chain. The approach works whether the agent runs on a cloud platform you do not control (such as ChatGPT, Claude.ai, Microsoft Copilot), inside a self-hosted runtime or anywhere in between. It does not require the agent platform to expose any instrumentation hooks. The cost is that enforcement only exists where vendors have built it. Once the agent holds that token, the IdP has no visibility into what happens next. Okta and CyberArk are building runtime controls for this layer, but both remain limited: Okta's Agent Relay is in early access, not general availability,[[9]](https://www.okta.com/blog/ai/okta-ai-agents-early-access-announcement/) CyberArk's AI Agent Gateway works only within its own identity stack.[[10]](https://www.cyberark.com/press/cyberark-introduces-first-identity-security-solution-purpose-built-to-protect-ai-agents-with-privilege-controls/) Both depend on every downstream app vendor cooperating. Getting hundreds of apps to implement governance hooks takes years, not months. And even when apps cooperate, neither approach gives you per-action visibility across tools. No app-vendor approach today offers per-action governance across multiple applications. ## How Cakewalk Turns a Gateway Into Governance Which of the four would have stopped Kiro's delete? The SDK would have needed Kiro's platform to instrument itself. The kernel would have seen the system call but not the intent. A vendor app hook only exists where the vendor has built one. Only the protocol gateway needs nothing new from either side. It is the one position every tool call has to pass through and no agent can route around. That is where Cakewalk runs. The tradeoff is visibility. The gateway sees every action the agent tries to take against the outside world, but not the internal reasoning. That is the surface that matters when something goes wrong. Governance has to run at machine speed, or it becomes the bottleneck that defeats the point of agent delegation. The gateway evaluates each action against policy deterministically, matching rules rather than asking the model. Every decision is auditable and reproducible before the action executes. A gateway by itself is a checkpoint, not governance. What turns a checkpoint into governance is the context around every decision it makes. ### The gateway inherits its context from the identity platform An [MCP gateway](/glossary/mcp-gateway) sits between an agent and the tools it calls. On each call, it sees two things: the name of the tool being invoked and an allowlist configured at setup. That catches the obvious: tools not on the allowlist, MCP servers the organization never approved. It misses what makes an action safe or unsafe. That takes three inputs: the kind of action, the human behind the agent and the system the agent is calling. Cakewalk's gateway evaluates all three on every call: the action, the user behind the agent and the target app. Actions are Read, Write, Destructive or External. The user brings department, seniority and role, pulled automatically from HR systems or IdPs. Target apps carry risk level, [data classification](/glossary/data-classification) and category. A read from the CFO on an internal document runs clean. The same call from a contractor on a customer-data app escalates. The same tool triggers a different decision. The same logic extends beyond your own org. When a customer's [data processing agreement](/glossary/data-processing-agreement) names the employees who may touch their data, the gateway needs to know who is asking, not what is being asked. All of this requires an [identity governance](/glossary/iga-identity-governance) platform underneath: users, roles, departments, app risk classifications, permission models, approval workflows and audit infrastructure. Cakewalk already operates that platform. A gateway without an identity platform underneath would need to build it. ### The agent's context grows as the task unfolds Most gateways give an agent a fixed set of tools at setup time. The agent's knowledge boundary is decided before the task begins and does not move. This is static agent context. It is the default model in MCP gateways, agent SDKs and vendor app integrations. If the task needs a tool the agent was not configured for, the task either fails or completes with degraded output. Cakewalk inverts that default. Every agent starts each task with no context at all. As the task progresses, every approved access request expands the agent's working context by one tool. Cakewalk calls this [Dynamic Agent Context](/glossary/dynamic-agent-context). **Definition: Dynamic Agent Context.** A governance model introduced by Cakewalk and unique to the Cakewalk gateway. The agent enters every task with no tool access. Each approved request grants one tool, scoped to that task only. When the task ends, every grant is revoked. The agent never accumulates standing access. No other gateway, SDK or identity platform implements this model today. Two boundaries hold the model together. The outer boundary is the total information surface of your company: every app, every dataset, every tool your org runs. It is the ceiling of what any agent could act on. The inner boundary is your agent's Dynamic Agent Context: what it currently knows about and can act on. It starts at zero on every task, grows one tool at a time and collapses back to zero when the task ends. The outer boundary does not move. Each expansion follows a different path depending on how far the tool is from what the agent can currently access. A tool the agent already holds credentials for requires only a policy check. If the user can access a tool but the agent cannot yet, the user authenticates. A tool the user does not have access to triggers a full request through the company's approval chain. On approval, Cakewalk's provisioning agent handles the rest: account created, permissions assigned, agent connected. Just-in-time provisioning at runtime, not a ticket in an IT queue. ### The gateway evaluates every action against policy What decides each expansion? A product manager asks their agent to analyze customer churn. The first time the agent calls a CRM tool, the call passes through the gateway. The gateway evaluates the call against the user, the action and the target app. The engine returns one of three outcomes. Escalate if the data is classified as sensitive. Deny if it violates policy. Approve if the user has CRM access and the action is a read. Escalations trigger a pattern Cakewalk calls [Suspend-and-Resume](/glossary/suspend-and-resume). The gateway holds the connection while a different human reviews the request: a manager, a security admin, an app owner. Not the user who initiated the task. To the agent, this looks like a slow tool call. Denials return a structured response so the agent can adapt or surface the reason to the user. Every decision is captured in the Decision Trace. If approved, the gateway decrypts the stored credential and injects it into the outbound call. The agent never sees the real credential. The agent's Dynamic Agent Context has grown by one tool. When the task ends, the inner boundary collapses to zero, while the outer boundary stays unchanged. ### Every call is auditable back to a human Every tool call produces a Decision Trace: a structured, immutable record. It captures who delegated, which policy fired, what inputs matched, who approved, what executed and when access ended. One call, one trace. A marketing manager asks their agent to pull campaign performance from HubSpot. The gateway intercepts the call, evaluates it against the manager's role and HubSpot's risk classification, then approves. The gateway injects the credential from the vault and the agent pulls the data. The trace lands before the call leaves. The point is queryability. Ask “who approved this agent's access to customer data?” and the answer is a name, a policy and a timestamp. Ask “who owns this agent?” and the answer traces to the delegating user, their department and their current employment status. Log files would require parsing free text across systems. Because the trace is tied to identity, lifecycle changes propagate automatically. When an employee in your org is offboarded, their agents lose access the moment they do. Role changes adjust agent access without manual intervention. ### Agents hold zero standing privileges Every tool call, every credential exchange and every policy decision passes through the gateway. A component with that much control over your security posture needs to earn trust through architecture, not promises. The gateway persists the credential in encrypted form in a per-tenant database, never in plaintext. It decrypts the credential server-side at the moment of each tool call and injects it into the outbound request. Agents never see real tokens. The credential is never exposed to the agent or the model. ## Governed Agents Run Autonomously Our previous article, [_The New Frontier in Identity Security: AI Agent Access_](/blog/the-new-frontier-in-identity-security-is-ai-agent-access), laid out the bind every security team faces. Block agents outright or allow them without controls. Companies are not stuck because they distrust agents. They are stuck because no governance layer lets them deploy agents at full speed. The first option destroys the productivity gain agents promise. The second opens risk that compounds with every tool they call. The third path exists. Policy-driven governance that lets agents operate autonomously with real-time evaluation at every action. Low-risk actions execute at machine speed. Sensitive actions escalate to the right human. External actions wait for the [human in the loop](/glossary/human-in-the-loop). Destructive actions are denied outright. Access is provisioned when needed and revoked when the task completes. Every decision traces back to a human. Governance and autonomy. Not governance or autonomy. ## References 1. Anthropic (2024). Introducing the Model Context Protocol. 2. Google Developers (2025). A2A: A New Era of Agent Interoperability. 3. Kasselman, Lombardo, Rosomakho, Campbell (2026). AI Agent Authentication and Authorization. 4. Rosenberg (2025). AAuth: Agentic Authorization OAuth 2.1 Extension. 5. Abbey, Cohen (Okta) (2025). SCIM Agents and Agentic Applications Extension. 6. OWASP (2025). Agent Name Service (ANS) for Secure AI Agent Discovery v1.0. 7. Errico (2026). Autonomous Action Runtime Management (AARM): A System Specification for Securing AI-Driven Actions at Runtime. 8. Oasis Security (2025). Cursor & Oasis: Intent-Based Access & Governance for AI Agents. 9. Okta (2026). Every Agent Needs an Identity: Introducing Okta for AI Agents in Early Access. 10. CyberArk (2025). CyberArk Introduces First Identity Security Solution Purpose-Built to Protect AI Agents with Privilege Controls. 11. AWS (2025). Amazon Verified Permissions. 12. AWS (2026). Amazon Bedrock AgentCore. 13. StackOne (2026). MCP: What's Working, What's Broken, and What Comes Next. 14. Anthropic (2025). Donating the Model Context Protocol and Establishing the Agentic AI Foundation. 15. GovInfoSecurity (2026). Autonomous Agent Hacked McKinsey's AI in 2 Hours. 16. Cakewalk (2026). The New Frontier in Identity Security: AI Agent Access. --- # Top 8 Identity and Access Management Tools for AI Agents in 2026 _Identity and access management was built for humans, then stretched to cover service accounts. Neither model holds up for AI agents. This guide compares the 8 platforms worth evaluating for AI agent IAM in 2026._ By Gil Röder, CPO & Co-Founder Published: 2026-04-02 Source: https://www.cakewalk.security/blog/best-identity-access-management-tools-ai-agents --- Identity and access management was built for humans logging in to apps. Over time, it stretched to cover [service accounts](/glossary/service-account) holding long-lived [API keys](/glossary/api-key). Neither model holds up for AI agents. Agents aren't users. They aren't service accounts. They're software that decides what to do, spawns sub-agents to carry out the work, calls tools across multiple SaaS apps in seconds, and disappears when the task is done. The credentials they need are scoped to a task, not a role. The actions they take need policy evaluation at the moment of execution, not provisioning approval six weeks earlier. Most existing IAM stacks weren't designed for any of that. A new generation of platforms has built around that reality. Most are recent. Many are well-funded. A few are already inside acquisitions: Cisco announced a $400M acquisition of Astrix Security in early May 2026. The category goes by several names: agentic identity, AI agent IAM, [non-human identity](/glossary/non-human-identity) for AI, agentic access management. The substance is consistent. It's identity for agents, with everything that follows from treating an agent as a first-class identity rather than an exception inside a human IAM system. This guide covers the 8 platforms worth evaluating. [Cakewalk](/) is first because it ships [purpose-built AI agent access management as a dedicated product with free early access](/agent-access-management), with a policy-first runtime gateway, ephemeral credentials, and unified governance for human and agent identities in a single platform. The other 7 are pure-play or near-pure-play agentic identity vendors evaluated on their actual coverage and trade-offs. ## What "identity and access management for AI agents" really means Worth pinning down. Traditional IAM has three layers: authentication (who are you), authorization (what can you do), and lifecycle management (when does that change). For agents, every layer is different. **Authentication.** Agents don't enter passwords. They authenticate through service tokens, [OAuth](/glossary/oauth) flows on behalf of users, [MCP](/glossary/model-context-protocol) server handshakes, or workload identity assertions. A useful IAM platform for agents understands these methods and treats agents as identities in their own right, with provenance you can trace back to the human who delegated the task. **Authorization.** A human user gets a role and a set of entitlements, generally for as long as they hold the job. An agent should get permissions scoped to one task, evaluated at runtime, expiring on completion. "Access to Salesforce" is the wrong abstraction. "Update one opportunity in Salesforce, on behalf of this specific user, for the next 90 seconds" is closer. **Lifecycle management.** Human employees join, change roles, and leave. Agents spawn, do something, and die, often within seconds. Lifecycle for agents is a runtime question, not a quarterly review. Discovery, provisioning, monitoring, and decommissioning have to be continuous and automated, because there's no manager to ask. The platforms in this guide approach these three layers from different starting points. Some come from non-human identity security. Some come from workload identity. Some come from human [IGA](/glossary/iga-identity-governance) and are extending into agents. Cakewalk is the platform built for both humans and agents in a single system, which matters more than it sounds because the day-to-day reality of most organizations is that the two are deeply intertwined: agents act on behalf of humans, and the delegation chain is the [audit trail](/glossary/audit-trail). ## What to look for in an AI agent IAM tool A few selection criteria worth holding vendors to. **Coverage of how agents actually authenticate.** Not just "we discover agents." Does the platform speak OAuth, OIDC, service tokens, MCP, and workload identity? Can it tie an agent's actions back to the human who initiated the work? **Runtime authorization at the tool-call level.** Policy enforcement at the moment of action. Auto-approve, escalate, or deny based on action type, target system, user context, and risk. Not [access reviews](/glossary/access-review) three months later. **Just-in-time, ephemeral credentials.** [Zero standing access](/glossary/zero-standing-permissions). Permissions granted for the task, scoped to the task, expired on completion. If the platform's answer is "long-lived API key, but stored in a vault," that's a vault, not agent IAM. **Full audit trail with delegation chain.** Who initiated the agent. Whose identity it acted under. Which policy fired. What changed. Exportable, queryable, audit-ready. **Discovery beyond your **[**IdP**](/glossary/identity-provider)**.** [SSO](/glossary/sso) is the floor. Agents act through [MCP servers](/glossary/mcp-server), custom code, and third-party platforms your directory was never designed to inventory. The [App and AI Discovery](/application-ai-visibility-and-control) capability is one of the few that's built around this reality. **Unified human and non-human governance.** Almost every agent acts on behalf of a human. If those two identity worlds live in separate systems, your audit story has gaps and your access reviews can't trace delegation cleanly. **Pricing that doesn't tax adoption.** Agent counts grow fast. Per-agent pricing creates an incentive to under-register agents, which defeats the point. Free tiers, generous starting plans, or unified pricing models matter in this category. **Time to value.** Self-serve setup. Operating in days, not after a six-month implementation. Agent adoption isn't waiting for your procurement process. ## AI agent IAM platform comparison | Platform | Best fit | Approach | Free tier? | | --- | --- | --- | --- | | Cakewalk | Mid-market B2B (100-800 employees) | Unified IAM for humans and AI agents with runtime policy gateway | Yes, free early access | | Oasis Security | Regulated Fortune 500 enterprises | NHI-first platform with Agentic Access Management extension | No (enterprise sales) | | Astrix Security | Cisco-aligned enterprise buyers | NHI security and AI agent governance, being acquired by Cisco for $400M | No (enterprise sales) | | Aembit | Engineering-led workload identity buyers | "IAM for agentic AI and workloads" with secretless access | No (enterprise sales) | | Token Security | Identity-led security teams | Identity-first AI security with MCP and AI agent lifecycle management | Partial (free Privilege Guardian tool) | | Opal Security | Engineering-heavy orgs | Developer-native access governance with Paladin AI evaluation agent | No (enterprise sales) | | ConductorOne | US enterprise | AI Access Management product on top of NHI governance | No (enterprise sales) | | Andromeda Security | Mid-market to enterprise unified-identity buyers | Unified platform for humans, NHIs, and agentic AI | No (enterprise sales) | ## Top 8 identity and access management tools for AI agents ### 1. Cakewalk [Cakewalk](/) is the agentic identity governance platform for fast-moving B2B companies, and the only platform on this list that ships [AI agent access management as a dedicated product with free early access](/agent-access-management). For mid-market teams (roughly 100 to 800 employees), Cakewalk solves a problem the rest of the list either approaches from one side (humans, with agents bolted on) or the other (NHIs, with humans handled somewhere else): IAM for humans and AI agents in a single system, with the same [policy engine](/glossary/policy-engine), the same audit trail, and the same operating model. The architecture is the differentiator. Cakewalk Gateway sits between agents and target apps. Every tool call gets evaluated against your policies before it executes. Auto-approve, escalate, or deny based on action type, user attributes, app category, and context. Decisions are deterministic. No LLM in the enforcement path. Permissions are granted just in time and scoped to the task; credentials expire on completion. Session ends, access ends, audit trail recorded. A few capabilities worth flagging: - **Real-time discovery** of every agent and AI tool across your stack, including the ones nobody told IT about. The [App and AI Discovery](/application-ai-visibility-and-control) layer covers managed and unmanaged apps, with 5,600+ integrations. - [**Dynamic agent context**](/glossary/dynamic-agent-context)**.** Static context limits results; Cakewalk adapts the agent's context boundary to each task. [Agent Cake](/agent-cake) provisions the right tools mid-task, governed by your policies, with no human in the provisioning loop. - **Unified IAM for humans and AI agents.** Cakewalk consolidates [employees, contractors, and AI agents](/platform-overview) in one system of record. Every agent action ties back to the human who delegated it, with full identity provenance. - [**Automated provisioning**](/auto-provisioning)**, **[**user access reviews**](/user-access-review-software)**, and **[**RBAC/ABAC**](/rbac-abac-software) for the human identity side, integrated with the same agent governance layer rather than sitting in a separate platform. - **Audit trail for every agent action.** Full delegation chain: who initiated, which user's identity the agent acted under, which policy applied, what changed. Queryable, exportable, and built for [SOC 2 and ISO 27001 audits](/access-control-audits). - **Self-serve setup.** Most teams go live in 1-2 weeks. Customers include ElevenLabs, Mentimeter, Almedia, PolyAI, FreeAgent, Cluepoints, Prolific, Dust, Manual, and Teamtailor. The platform is [ISO 27001](/glossary/iso-27001) certified, [GDPR](/glossary/gdpr) compliant, holds 5/5 stars on G2, and is supported by Google for Cybersecurity. The [ElevenLabs case study](/customers/how-elevenlabs-automated-access-management-to-keep-up-with-hyper-growth) describes the operating model in practice for a high-growth AI company. The free early access for [agent access management](/glossary/agent-access-management) is the differentiator in this category. Every other platform on this list either charges enterprise pricing or buries agent governance inside a license tier that requires a sales call. Cakewalk's [agent access management is in beta and free to sign up for now](/agent-access-management). **Best fit:** mid-market B2B companies running on Google, Entra, or Okta as their IdP, looking for unified IAM that covers humans and AI agents in one platform. Companies preparing for [SOC 2](/glossary/soc-2) or ISO 27001 audits, dealing with audit findings, or feeling enterprise sales pressure on [access control](/glossary/access-control) should look here first. [Get free early access to Cakewalk](/agent-access-management) or [book a demo](/book-demo). ### 2. Oasis Security [Oasis Security](https://www.oasis.security/) brands its product as "Agentic Access Management" on the homepage, with a clear thesis: access control that understands intent, not just static roles. In March 2026 the company raised a $120M Series B led by Sequoia and Craft, on the back of customer momentum in regulated industries. Mars, Blue Cross Blue Shield, Citizens Financial, and BHG Financial are public references. The platform's roots are in non-human identity inventory, ownership mapping, and lifecycle management for service accounts, secrets, and machine identities. The agentic access management product extends that foundation specifically to AI agents: inventory of every agent, automated agent identity provisioning, time-bound access scoped to intent, and policy enforcement across AWS, Azure, GCP, Snowflake, Databricks, GitHub, Salesforce, Office 365, Copilot, OpenAI, and the rest of the modern AI stack. Customer outcomes Oasis publishes lean enterprise: a Fortune 50 healthcare provider avoiding a $3-5M [HIPAA](/glossary/hipaa) breach fine, a Fortune 500 insurance company capping an outage, a Fortune 300 CPG cutting attack surface 60% during a proof of value. SOC 2 and ISO 27001 certified. Trade-offs: Oasis is enterprise-priced and enterprise-positioned. No free tier or self-serve trial. Pricing is sales-led only. The platform's center of gravity is NHI security for regulated Fortune 500 organizations, which is a strength if that's you and a different fit if you need unified human and agent governance in one platform. **Best fit:** large regulated enterprises (finance, healthcare, insurance, energy) extending an existing NHI program to cover AI agents. ### 3. Astrix Security [Astrix Security](https://astrix.security/) is the non-human identity security platform that Cisco announced acquiring for $400M in early May 2026. The deal is meaningful context for any buyer evaluating Astrix today: the platform is being folded into Cisco Identity Intelligence, Duo IAM, and Secure Access, which signals strong long-term roadmap support but also platform churn during integration. The product itself is a credible pure-play agentic identity platform. Astrix calls it the "Agent Control Plane" and positions specifically against the gap traditional IAM leaves: service accounts, API keys, OAuth tokens, and AI agents all sitting outside the identity perimeter. Discovery, governance, lifecycle management, threat detection, and secrets management across cloud, SaaS, and on-prem. The customer base includes Xerox and HubSpot. The Astrix value proposition is built around enterprise NHI security with AI agent coverage layered on top, similar in shape to Oasis but with a deeper threat detection story. Cisco's acquisition rationale is essentially to plug agent identity into its existing [zero-trust](/glossary/zero-trust) portfolio. Trade-offs: the Cisco acquisition adds platform risk in the form of integration uncertainty over the next 12-18 months. Pricing is enterprise sales only. As a standalone platform, Astrix is strong; as part of Cisco's eventual integrated offering, the shape will change. **Best fit:** enterprises already in the Cisco security ecosystem, or large organizations that want NHI security with a clear acquirer integration path. ### 4. Aembit [Aembit](https://aembit.io/) describes itself as "IAM for agentic AI and workloads" directly on the homepage, which is the most on-the-nose positioning in the category. The platform's roots are in workload identity (specifically secretless access for non-human workloads), and the product has extended naturally to cover AI agents as a particular kind of workload. The architecture's distinguishing trait is secretless access. Instead of agents holding credentials they could leak, Aembit issues short-lived authentication tokens at runtime, with policies that evaluate identity, posture, and context before granting access. For engineering-led teams building agents in-house, the developer experience is strong: integrations are workload-friendly, policy-as-code is supported, and the architecture sits naturally inside zero-trust deployments. The trade-off shows up on the human side. Aembit is built for workload-to-workload and agent-to-service access, not for human identity governance. Companies that need both human IGA and agent IAM in one platform will end up pairing Aembit with another tool, which adds operational overhead. **Best fit:** engineering-led organizations with platform teams building AI agents and workloads in-house, needing secretless authentication and runtime policy enforcement. ### 5. Token Security [Token Security](https://www.token.security/) is a Tel Aviv-based pure-play non-human identity security platform with a strong AI agent angle. The company raised a $20M Series A from Notable Capital in January 2025, bringing total funding to $27M, and reported triple-digit revenue growth across 2025. Customers include HPE and Hibob. The company is backed by industry veterans including Kevin Mahaffey (Lookout founder) and Shlomo Kramer (Cato Networks co-founder). The product covers discovery, lifecycle management, security posture, and threat detection for both machine identities and AI agents. Notable product launches in 2025 included the industry's first MCP server for agentic AI and NHI security (lets security teams query AI and machine identities through natural language), an AI Discovery Engine, an AI Agent Lifecycle Management capability for joiner-mover-leaver workflows applied to AI agents, and a free AI Privilege Guardian tool for right-sizing agent permissions. The platform's framing is "identity-first AI security," with the consistent message that traditional IAM fails because it treats machines like people. The capability mix leans more toward visibility, governance, and posture than runtime enforcement at the tool-call level. Trade-offs: enterprise sales only for the full platform. Strong on AI agent identity lifecycle and discovery, lighter on runtime policy enforcement at the action level compared to platforms with a dedicated gateway architecture. **Best fit:** identity-led security teams wanting deep NHI and [AI agent governance](/glossary/ai-agent-governance) with strong MCP support. ### 6. Opal Security [Opal Security](https://www.opal.dev/) launched Paladin (an AI access evaluation agent) and three new AI-native capabilities in March 2026, positioning around access governance with AI as a first-class participant. The platform pairs deep developer-native integrations (Terraform, Slack, Jira, PagerDuty, GitHub) with just-in-time access controls and a Risk Layer for AI agent governance. For engineering-heavy organizations, Opal is a strong fit. The developer tooling is among the best in this category, the JIT access controls genuinely reduce standing privileges, and Paladin brings an AI evaluation layer to access decisions. The 2025 Risk Layer added purpose-built governance for AI agents on top of the existing human access governance foundation. Where Opal sits on the agentic identity spectrum is closer to "access governance platform with AI agent extensions" than pure-play agentic IAM. That's not a knock. For engineering-led teams whose primary pain is human access combined with growing AI agent governance needs, Opal covers both. It's just a different center of gravity from the NHI-first platforms. Trade-offs: smaller connector library than enterprise IGA platforms. Enterprise sales motion. The platform's center of gravity is engineering-led security teams, which is a strength if that's your team and a limitation if it isn't. **Best fit:** engineering-heavy organizations with platform engineering teams wanting governance to live close to infrastructure, with AI agent governance layered on top. ### 7. ConductorOne [ConductorOne](https://www.conductorone.com/) is the enterprise identity governance platform that announced its AI Access Management product extension in March 2026, treating AI agents as first-class identities with credentials, policies, lifecycle states, and ownership. The company raised a $79M Series B in October 2025, led by Greycroft with CrowdStrike Falcon Fund participating. The platform's strengths are the Unified Identity Graph (300+ connectors with real-time schema), 3,000+ hosted MCP servers built on the existing connector ecosystem, fine-grained tool-call authorization, credential vaulting, and a strong story around just-in-time access. The non-human identity governance layer launched in 2025 and now sits beneath the agent product. ConductorOne grew from human IGA into AI agents, which gives the platform a more enterprise-ready governance story than pure-play agent platforms. The trade-off is that the AI Access Management product is newer than the underlying IGA layer, so the agent-specific capabilities are still maturing. Trade-offs: enterprise-priced and enterprise-positioned. No free tier. Self-serve provisioning is real but the platform is built for organizations with dedicated identity teams. Mid-market companies often find themselves looking at price tags and connector counts they'll never use. **Best fit:** US enterprises with mature identity programs already running AI agents at scale. ### 8. Andromeda Security [Andromeda Security](https://www.andromedasecurity.com/) is an AI-powered identity security platform that positions itself as "the pioneer in treating agentic AI as a full identity class." The company launched its "Galaxy" release in March 2026, extending continuous access intelligence and automated governance controls to AI agents alongside its existing human and NHI governance. The platform's distinctive feature is the unified architecture for humans, NHIs, and AI agents, combined with AI-powered just-in-time access decisions driven by risk and behavioral context. Galaxy added universal agent discovery, agent access intelligence, omni-dimensional segregation of duties enforcement across all identity types, and automated ownership workflows for non-human identities. Andromeda reports doubling revenue every quarter for the past year, with customers including New American Funding. Funding-wise Andromeda is smaller than the other platforms on this list, with $7M raised from the AWS and CrowdStrike Cybersecurity Accelerator, Sorenson Capital, and Lockstep (Palo Alto). The unified identity story is compelling but the platform is newer to market than Oasis or Astrix. Trade-offs: smaller team and customer base than the better-funded competitors. Enterprise sales motion. The unified identity story is strongest where buyers haven't already committed to a separate human IGA platform. **Best fit:** mid-market to enterprise organizations buying unified identity governance from a single platform, where AI agents are a meaningful (but not yet dominant) share of the identities under management. ## How to choose the right AI agent IAM platform The decision depends on what kind of identity program you're trying to run and how AI agents fit into it. If you're a fast-moving B2B company between 100 and 800 employees with AI agents already in production and audit conversations getting harder, [Cakewalk](/) is the most practical choice. Unified IAM for humans and AI agents, [free early access](/agent-access-management), and deployment timelines measured in weeks rather than months. The architecture is purpose-built for agent access with runtime policy enforcement, ephemeral credentials, and full delegation traces. If you're a regulated Fortune 500 with an existing NHI security program, Oasis Security and Astrix Security are the closest enterprise tier-up alternatives. Oasis is independent and well-funded. Astrix is mid-acquisition into Cisco, which is a long-term strength (Cisco distribution) and a short-term risk (integration uncertainty). If your team is engineering-led and building agents in-house, Aembit's workload identity approach with secretless access is the natural fit, or Opal's developer-native access governance if you want broader human-plus-agent coverage on the same platform. If you're an identity-led security team focused on visibility, lifecycle, and posture for the full non-human identity surface, Token Security has deep NHI and AI agent coverage with strong MCP support. If you're a US enterprise with a mature identity team and an existing budget for AI-native identity, ConductorOne is the closest tier-up alternative with strong analyst recognition and a dedicated AI Access Management product. If you want a unified platform that treats humans, NHIs, and agentic AI as one identity surface from day one, Andromeda Security's architecture is purpose-built for that. It's newer and smaller than the others, which is a feature (no legacy baggage) and a tradeoff (less proven at scale). For most mid-market companies evaluating this seriously, the practical decision comes down to [Cakewalk](/agent-access-management) (purpose-built, free early access, weeks to roll out, unified humans and agents) and one of the enterprise NHI platforms if you have the security maturity and budget to absorb the implementation. Worth getting hands on at least two before signing. [Sign up for free early access to Cakewalk](/agent-access-management) to see what unified IAM for humans and AI agents looks like running against your own environment. ## FAQ ### What is IAM for AI agents? IAM for AI agents is identity and access management designed for autonomous software that acts on behalf of users. It covers three things that traditional IAM doesn't handle well: how agents authenticate (often through service tokens, OAuth flows, MCP handshakes, or workload identity assertions rather than passwords), how their actions are authorized at runtime (per tool call, scoped to a task, with ephemeral credentials), and how their lifecycle is managed (continuous discovery and automated decommissioning rather than quarterly access reviews). [Cakewalk's AI agent access management product](/agent-access-management) is one of the few platforms built specifically for this category. ### How is AI agent IAM different from non-human identity (NHI) management? NHI management covers service accounts, API keys, machine identities, and other automated identities that have existed in IT environments for decades. AI agents are a subset of non-human identities, but they behave differently. Service accounts are deterministic: they do exactly what they were built to do. AI agents decide what to do, sometimes spawning sub-agents, sometimes calling tools the operator never approved. That difference means agent IAM needs runtime policy decisions, not just lifecycle credential management. Some platforms (Oasis, Astrix, Token Security) approach agent IAM as an extension of NHI security. Others (Cakewalk, Aembit) approach it as a distinct discipline with its own policy enforcement layer. ### Do I need separate tools for human IAM and AI agent IAM? Some platforms argue yes (specialize to win); others argue no (unify to govern). The practical reality is that most agents act on behalf of a human user, so the two identity worlds are deeply intertwined. Splitting them across two platforms creates audit gaps: when you ask "who approved this agent action," the answer has to traverse two systems. Cakewalk and Andromeda Security are the two platforms on this list that explicitly unify human and agent identity governance in one platform. Most others handle one well and bolt on the other. ### What about MCP servers and the security implications? Model Context Protocol (MCP) is increasingly how agents reach tools and data, especially as the standard matures through 2026. Some platforms (Cakewalk, Token Security, ConductorOne) explicitly handle agents acting through MCP servers, intercepting tool calls and applying policy. Token Security launched the first commercial MCP server for agentic AI security in 2025. If MCP is part of your stack, ask vendors specifically how they govern agent actions routed through arbitrary MCP servers. ### Is there a free tier or free trial for AI agent IAM? Most platforms in this category require a sales call and an annual contract. The exception is [Cakewalk's AI agent access management beta](/agent-access-management), which is in free early access while it ramps to general availability. Token Security offers a free AI Privilege Guardian tool for right-sizing agent permissions, though the broader platform is paid. Everything else (Oasis, Astrix, Aembit, Opal, ConductorOne, Andromeda) requires sales engagement to evaluate. ### Will Cisco's acquisition of Astrix Security affect my evaluation? Yes, in two ways. Long term, Astrix gains Cisco's distribution, integration with Cisco Identity Intelligence, Duo IAM, and Secure Access, and meaningful roadmap investment. Short term, expect platform integration churn through 2026 and 2027 as the product is folded into Cisco's broader security portfolio. If you're already a Cisco shop, the acquisition is net positive. If you're evaluating Astrix as a standalone purchase, factor in integration uncertainty. The deal was announced in early May 2026. ### How quickly can a team deploy AI agent IAM? This varies a lot across the category. Modern platforms designed for self-service (Cakewalk, Aembit, ConductorOne) can be operational in days to a couple of weeks, with the team running policies and seeing telemetry against real agents in that window. Enterprise platforms (Oasis, Astrix, Token Security, Opal, Andromeda) typically run multi-week evaluations with sales engineering support before deployment. The fastest path to actual governance signal in your environment is a self-serve trial against your real agents, which is one reason free early access matters in this category. [Cakewalk's free early access](/agent-access-management) gets most teams to first useful telemetry within hours. ### What does AI agent IAM typically cost? Pricing is opaque across the category, with vendors quoting per-employee, per-agent, per-connector, or hybrid rates that vary by deal. Every platform in this guide except Cakewalk requires a sales call to access AI agent governance. Cakewalk's [agent access management is currently free during the beta period](/agent-access-management), which is the only self-serve way to test purpose-built agent IAM against your real environment without entering a procurement cycle. --- # Top 10 AI Agent Security Tools for Access Management in 2026 _Compare the 10 best AI agent access management tools for 2026. Cakewalk leads with purpose-built runtime governance and free early access, plus 9 alternatives evaluated honestly._ By Gil Röder, CPO & Co-Founder Published: 2026-03-30 Source: https://www.cakewalk.security/blog/top-10-ai-agent-security-tools-access-management-2026 --- In 2026, AI agents are operational. Not pilots, not demos, not the future. Right now. ConductorOne's Future of Identity Report from March puts the number at 95% of organizations running AI agents that autonomously perform IT or security tasks, up from "we plan to" twelve months earlier. The same survey found that in 47% of organizations, non-human identities now outnumber human ones. Only 22% have full visibility into what those non-human identities can actually touch. That's the gap this guide is about. Most security teams are trying to govern agent access using tools designed for humans logging in to apps, or [service accounts](/glossary/service-account) that get a long-lived [API key](/glossary/api-key) and live forever. Neither model works for an agent that spawns, performs three tool calls across two SaaS apps, and dies in 90 seconds. The category responding to this is starting to settle, but it's noisy. Some vendors have built dedicated AI [agent access management](/glossary/agent-access-management) from the ground up. Some have bolted "agent identity" onto existing [IGA](/glossary/iga-identity-governance) platforms. A few are still shipping AI marketing on top of SaaS spend dashboards. This guide covers 10 tools worth considering. We've put [Cakewalk](/) first because it's the only one in the list that ships purpose-built [AI agent access management](/agent-access-management) with policy-first runtime enforcement, ephemeral credentials, and full delegation traces, and the only one currently offering [free early access](/agent-access-management). The other nine are evaluated honestly, with their actual agent capabilities (or lack thereof) called out where relevant. ## What is AI agent access management, really? The term gets stretched, so worth pinning down. AI agent access management is what an organization needs to do four things: 1. **Discover every agent.** Both the ones IT deployed and the ones a marketer signed up for last Tuesday using their work email. This includes Claude Desktop, ChatGPT enterprise connectors, Copilot agents, custom-built agents in Dust or LangGraph, and the long tail of [MCP](/glossary/model-context-protocol) servers your engineers are spinning up. 2. **Authorize at runtime, not at setup.** The hard part. An agent doesn't need "access to Linear." It needs to call create_issue once on behalf of a specific user, in a specific context, for a specific task. Static credentials granted at deployment violate every principle of [least privilege](/glossary/least-privilege) the moment the agent does anything beyond what it was first built for. 3. **Issue ephemeral credentials.** Tokens that live for the task, then die. Not 90-day [OAuth](/glossary/oauth) refresh tokens. Not service account keys that get rotated quarterly if someone remembers. 4. **Produce a full **[**audit trail**](/glossary/audit-trail)**.** Who initiated the action, which user delegated, which policy applied, what the agent actually did. Compliance frameworks haven't fully caught up to autonomous systems yet, but [ISO 27001](/glossary/iso-27001), [SOC 2](/glossary/soc-2), and the [EU AI Act](/glossary/eu-ai-act) (high-risk obligations effective August 2026) all push in this direction. If a tool covers identity inventory and ownership but doesn't enforce policy at the tool-call level, it's [NHI](/glossary/non-human-identity) inventory. Useful, but not access management. If it does runtime authorization but only for a closed ecosystem of agents you build inside its walled garden, it's an agent platform. Useful, but not coverage. ## What to look for in an AI agent access management platform A few things separate genuine AI agent access management from rebranded IGA. **Runtime policy enforcement at the tool-call level.** Every action an agent takes should be evaluated against your policies before it executes, not after the fact. Auto-approve, escalate, or deny based on action type, user attributes, app category, and context. **Deterministic enforcement.** No LLM should sit in the policy decision path. The agent uses an LLM to decide what to do; your access platform should not. Probabilistic enforcement is not enforcement. [**Zero standing access**](/glossary/zero-standing-permissions)**.** Agents should hold zero permissions by default. Permissions get granted just in time, scoped to the task, and expire on completion. Session ends, access ends. **Coverage beyond your **[**IdP**](/glossary/identity-provider)**.** [SSO](/glossary/sso) is the floor, not the ceiling. Agents act across SaaS apps that may or may not be in your IdP, against APIs that don't have SSO at all, and through [MCP servers](/glossary/mcp-server) that route requests in ways your directory was never designed to see. [Cakewalk's app and AI discovery](/application-ai-visibility-and-control) is one of the few approaches built around this reality. **Full delegation chain in the audit trail.** Who triggered the agent. Which user's identity it acted under. Which policy applied. What changed. Reproducible. Exportable. If your auditor asks "who approved this," the answer should not be "the system did." **Time to value.** Agent adoption isn't waiting for your six-month rollout. The platform should self-serve, integrate fast, and produce useful governance signal in days. If implementation requires a partner SOW, you've already lost the race against [shadow AI](/glossary/shadow-ai). **Pricing that doesn't punish you for adopting AI.** AI agents multiply. If the cost of governance scales linearly with agent count, your security team will quietly stop telling people to register agents. A free or generous starting tier matters more in this category than in any other identity tool. ## AI agent access management platform comparison | Platform | Best fit | Agent-specific approach | Free tier? | | --- | --- | --- | --- | | Cakewalk | Mid-market, fast-moving B2B (100-800 employees) | Purpose-built agent access management with runtime policy gateway | Yes, free early access | | ConductorOne | US enterprise | AI Access Management extension on top of NHI governance | No (enterprise sales) | | Lumos | Mid-market SaaS-heavy orgs | SaaS-first IGA, Albus AI for policy recs, weak on agentic identity | No (custom pricing) | | SailPoint | Large regulated enterprise | Agent Identity Security connectors (separate license) | No (enterprise sales) | | Okta IGA | Okta-first environments | Workflows-driven, agent-aware via Okta integrations | No (per-user tier) | | Microsoft Entra Agent ID | Microsoft-first enterprises | Agent identity blueprints, currently in PREVIEW | Tied to Microsoft 365 Copilot + Frontier | | Zluri | Mid-market, SaaS spend plus governance | Identity Security Platform with NHI discovery (March 2026) | No (custom pricing) | | Opal Security | Engineering-heavy orgs | Paladin AI evaluation agent, JIT access controls | No (enterprise sales) | | Trelica | 1Password customers | SaaS management with light governance, owned by 1P | No (enterprise sales) | | Oasis Security | Regulated Fortune 500 enterprises | NHI-first platform extended into agentic access management | No (enterprise sales) | ## Top 10 AI agent security tools for access management in 2026 ### 1. Cakewalk [Cakewalk](/) is the agentic identity governance platform for fast-moving B2B companies, and the only platform on this list that ships [AI agent access management as a dedicated product with free early access](/agent-access-management). For mid-market teams (roughly 100 to 800 employees) running AI-native operations, this is the most direct path from "we have agents in production" to "we can prove who delegated what, against which policy, and what happened next." The architecture matters here. Cakewalk Gateway sits between agents and target apps. Every tool call gets evaluated against your policies before it executes. Auto-approve, escalate, or deny based on action type, user attributes, and app category. Decisions are deterministic. No LLM in the enforcement path. Permissions are granted just in time and scoped to the task; credentials expire on completion. Session ends, access ends, audit trail recorded. A few capabilities worth flagging: - **Real-time discovery** of every agent and AI tool across your stack, including the ones nobody told IT about. The [App and AI Discovery](/application-ai-visibility-and-control) layer covers managed and unmanaged apps, with 5,600+ integrations out of the box. - [**Dynamic agent context**](/glossary/dynamic-agent-context)**.** Static context limits results; Cakewalk adapts the agent's context boundary to each task. [Agent Cake](/agent-cake) provisions the right tools mid-task, governed by your policies, with no human in the provisioning loop. - **Audit trail for every agent action.** Full delegation chain: who initiated, which user's identity the agent acted under, which policy applied, what changed. Queryable, exportable, and built for [SOC 2 and ISO 27001 audits](/access-control-audits). - **Coverage for human and non-human identities in the same platform.** Agent governance shouldn't be a separate license bolted onto an HR-driven IGA. Cakewalk consolidates [employees, contractors, and AI agents](/platform-overview) in one system of record. - **Self-serve setup.** Most teams go live in 1-2 weeks. Compare that to legacy IGA implementations measured in quarters. Customers include ElevenLabs, Mentimeter, Almedia, PolyAI, FreeAgent, Cluepoints, Prolific, Dust, Manual, and Teamtailor. The platform is ISO 27001 certified, [GDPR](/glossary/gdpr) compliant, holds 5/5 stars on G2, and is supported by Google for Cybersecurity. The [ElevenLabs case study](/customers/how-elevenlabs-automated-access-management-to-keep-up-with-hyper-growth) is worth reading if you're at a high-growth AI company facing the same problem. The free early access is the differentiator in this category. Every other platform on this list either charges enterprise pricing for agent governance or buries it inside a license tier that requires a sales call. Cakewalk's [agent access management is in beta and free to sign up for now](/agent-access-management). **Best fit:** mid-market B2B companies, particularly those running on Google, Entra, or Okta as their IdP and missing real governance for AI agents, fast-moving operations, and SaaS sprawl beyond SSO. Companies preparing for SOC 2 or ISO 27001, dealing with audit findings, or feeling enterprise sales pressure on [access control](/glossary/access-control) should look here first. [Get free early access to Cakewalk](/agent-access-management) or [book a demo](/book-demo). ### 2. ConductorOne [ConductorOne](https://www.conductorone.com/) is the closest enterprise-tier alternative if you're a large US organization buying on the strength of analyst recognition and an AI-native pitch. The company raised a $79M Series B in October 2025 (led by Greycroft, with CrowdStrike Falcon Fund participating) and announced its AI Access Management product extension in March 2026, treating AI agents as first-class identities with credentials, policies, lifecycle states, and ownership. The platform's strengths are the Unified Identity Graph (300+ connectors with a real-time schema), 3,000+ hosted MCP servers built on the existing connector ecosystem, fine-grained tool call authorization, credential vaulting, and a strong story around just-in-time access. The non-human identity governance layer launched in 2025, which now sits beneath the agent product. Trade-offs: ConductorOne is enterprise-priced and enterprise-positioned. There's no free tier. Self-serve provisioning is real but the platform is built for organizations with dedicated identity teams. Mid-market companies often find themselves looking at price tags and connector counts they'll never use. **Best fit:** US enterprises with mature identity programs already running AI agents at scale. ### 3. Lumos [Lumos](https://www.lumos.com/) is a SaaS-first IGA built around what your IdP already knows. The platform automates access requests through Slack, runs delta-only [access reviews](/glossary/access-review) (only what's changed since the last cycle), and ships Albus, an AI agent that watches access patterns and generates [RBAC](/glossary/rbac) policies based on peer behavior. For SaaS-heavy mid-market environments, the platform is genuinely useful. The self-service experience is solid and the Slack integration reduces ticket volume. But on agent identity specifically, Lumos is a bolt-on. Industry analysts have repeatedly flagged that support for non-human identities and agentic identities is weaker than competitors purpose-built for the category. The platform's data model is built around what's in the IdP; AI agents that act through [MCP gateways](/glossary/mcp-gateway) or sit outside SSO are a blind spot. Trade-offs: custom pricing (no public tiers, no free tier), shallow data model on entitlements inside individual apps, and a roadmap still catching up to the agent identity question. **Best fit:** mid-market SaaS-heavy organizations whose primary pain is human access requests and self-service. ### 4. SailPoint [SailPoint](https://www.sailpoint.com/) is the legacy enterprise IGA suite. In 2026, the company expanded its Agent Identity Security connectors to cover SaaS Salesforce, ServiceNow, and Snowflake, enabling discovery and governance of AI agents inside those platforms. The company also formalized an "adaptive identity" strategy positioning the platform around real-time, risk-context-driven access decisions. For Fortune 500 organizations with deep SAP integration, multi-country compliance burdens, and dedicated IAM teams, SailPoint remains the analyst-favored choice. The integration library is the biggest in the category. The trade-offs that matter for AI agent access specifically: governance of agent identities requires a separate Agent Identity Security license. Implementation timelines stretch into quarters or years for large rollouts. The administrative console is consistently flagged as less intuitive than newer cloud-native platforms. For a fast-moving company that just needs to govern Claude Desktop sessions across 200 employees, SailPoint is heavy machinery. **Best fit:** large regulated enterprises with mature IAM programs and the budget to absorb professional services. ### 5. Okta IGA [Okta Identity Governance](https://www.okta.com/products/identity-governance/) extends Okta's IdP into the governance layer. Workflows handle automation, access certifications run on schedule, and the platform integrates with Okta's broader product line. For organizations already standardized on Okta as their IdP, this is the lowest-friction path to add IGA capabilities without introducing another vendor. Agent-specific capabilities are growing through the Okta ecosystem (the company has been positioning around [AI agent governance](/glossary/ai-agent-governance), including an Auth for GenAI offering and a partnership with Anthropic), but the platform's center of gravity is human identity governance. Configuration burden sits on administrators through Workflows, which means smaller teams without dedicated Okta admins can struggle. Trade-offs: per-user tiered pricing, configuration complexity, and an agent identity story that's still in motion. **Best fit:** Okta-first environments with internal Okta expertise. ### 6. Microsoft Entra Agent ID [Microsoft Entra Agent ID](https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-agent-id) is Microsoft's purpose-built identity layer for AI agents, currently in PREVIEW as of early 2026. The model uses agent identity blueprints (templates that hold credentials and policies) to spawn agent identities at scale. It's tightly integrated with Conditional Access, Entra ID Governance, and Microsoft Agent 365. If you're a Microsoft-first enterprise running Copilot Studio agents, Microsoft 365 Copilot, or building agents inside the Microsoft ecosystem, Entra Agent ID is the natural choice. The ambition is enterprise-scale: bulk creation, lifecycle management, and policy inheritance across thousands of agents. Trade-offs that buyers should weigh carefully: - The capability is in **preview**. Microsoft explicitly warns features and pricing may change before general availability. - Access requires an active Microsoft 365 Copilot license with the Frontier program enabled. - A privilege escalation flaw in the Agent ID Administrator role was disclosed and patched on April 9, 2026, after a security researcher demonstrated full service principal takeover. Microsoft fixed it; the incident illustrates how new the surface area is. - Coverage is strong inside the Microsoft estate and weaker for agents acting on third-party SaaS or open-source MCP servers. **Best fit:** large Microsoft-first enterprises building inside Copilot Studio with the Frontier license to match. ### 7. Zluri [Zluri](https://www.zluri.com/) expanded into the Zluri Identity Security Platform in March 2026, adding NHI and AI agent discovery on top of the company's longstanding SaaS management foundation. The platform's nine-method discovery engine remains one of the strongest approaches to surfacing [shadow IT](/glossary/shadow-it), including unmanaged agents. The pivot is recent. Zluri's roots are in SaaS spend optimization and license management, and the governance capabilities have been growing on top. The Identity Risk Intelligence System correlates signals across human and non-human identities to flag risk, but enforcement at the tool-call level isn't really the architecture. Trade-offs: agent governance is identity-discovery-led rather than runtime-enforcement-led. Pricing requires a sales call. The platform shines on visibility and falls short of platforms that intercept and authorize agent actions at runtime. **Best fit:** mid-market organizations whose primary problem is "we don't know what AI tools or agents are running." ### 8. Opal Security [Opal Security](https://www.opal.dev/) launched Paladin (an AI access evaluation agent) and three new AI-native capabilities in March 2026, positioning around access governance with AI as a first-class participant. The platform pairs deep developer-native integrations (Terraform, Slack, Jira, PagerDuty, GitHub) with just-in-time access controls and a Risk Layer for AI agent governance. For engineering-heavy organizations, Opal is a strong fit. The developer tooling is among the best in this category, and the JIT access controls genuinely reduce standing privileges. The 2025 Risk Layer adds purpose-built governance for AI agents. Trade-offs: smaller connector library than SailPoint or Saviynt. Enterprise sales motion. The platform's center of gravity is engineering-led security teams, which is a strength if that's your team and a limitation if it isn't. **Best fit:** engineering-heavy organizations with platform engineering teams that want governance to live close to infrastructure. ### 9. Trelica [Trelica](https://www.trelica.com/) was acquired by 1Password in January 2025 and now sits inside 1P's identity portfolio. The platform's roots are in SaaS portfolio management and license optimization, with no-code workflow building, automated discovery, and a searchable app catalog for sanctioned tools. The 1Password acquisition gives Trelica significant distribution. If you're already a 1P customer at scale, the bundle math gets interesting. Agent-specific capabilities are growing through the integration with 1P's identity stack, but the platform's foundation is SaaS spend and license management rather than runtime agent authorization. Trade-offs: focus is still SaaS portfolio management, not deep identity lifecycle or runtime agent governance. Enterprise sales model. **Best fit:** 1Password customers wanting to consolidate SaaS management and lightweight governance under one vendor. ### 10. Oasis Security [Oasis Security](https://www.oasis.security/) is the non-human identity (NHI) platform that's pushed hardest into the agent space, branding the category "Agentic Access Management" on its own product page. The pitch: access control that understands intent, not just static roles and permissions. In March 2026 the company raised a $120M Series B led by Sequoia and Craft, on the back of customer momentum in regulated industries (Mars, Blue Cross Blue Shield, Citizens Financial, BHG Financial, and several other Fortune 500s). The platform's roots are in non-human identity inventory, ownership mapping, and lifecycle management for service accounts, secrets, and machine identities. The agentic access management product extends that foundation to AI agents specifically: inventory of every agent, automated agent identity provisioning, time-bound access scoped to intent, and policy enforcement across AWS, Azure, GCP, Snowflake, Databricks, GitHub, Salesforce, Office 365, Copilot, OpenAI, and the rest of the modern AI stack. The customer outcomes Oasis publishes lean enterprise: a Fortune 50 healthcare provider avoiding a $3-5M [HIPAA](/glossary/hipaa) breach fine, a Fortune 500 insurance company capping an outage that affected half its production workloads, a Fortune 300 CPG cutting attack surface 60% during a proof of value. SOC 2 and ISO 27001 certified, with a wall of awards from theCUBE, Cyber Defense Magazine, and CRN. Trade-offs: Oasis is enterprise-priced and enterprise-positioned. Pricing is sales-led only with no free tier or self-serve trial, so evaluation runs through a procurement cycle. The platform's center of gravity is NHI security for regulated Fortune 500 organizations, which is a strength if that's you and a different fit if you're a mid-market AI-native company that needs human and agent governance unified in one place. **Best fit:** large regulated enterprises (finance, healthcare, insurance, energy) that already have a non-human identity problem and are extending governance to cover AI agents. ## How to choose the right AI agent access management platform The right tool depends on what kind of agent governance you're actually trying to run. If you're a fast-moving B2B company between roughly 100 and 800 employees with AI agents already in production and audit conversations getting harder, [Cakewalk](/) is the most pragmatic choice. The architecture is purpose-built for agent access (runtime policy gateway, ephemeral credentials, full delegation traces), the deployment timeline is days to weeks rather than months, and the [free early access tier](/agent-access-management) lets you test it against your real environment before committing budget. If you're a US enterprise with a mature identity team and an existing budget for AI-native identity, ConductorOne is the closest tier-up alternative. Strong analyst recognition, deep connector library, and now a dedicated AI Access Management product. If you're a Fortune 500 with deep SAP, multi-country compliance, and a dedicated IAM team, SailPoint remains the heavy-lift choice. Add their Agent Identity Security license and budget for professional services. If you're already standardized on Microsoft 365 Copilot with Frontier enabled, Microsoft Entra Agent ID is the natural play, but plan for preview-stage limitations. If your stack is engineering-led with platform teams that live in Terraform and Slack, Opal Security's developer-native approach will feel right. If your primary problem is "we don't know what AI tools are running in our org," Zluri's discovery engine is among the strongest. Pair it with a runtime governance layer to actually enforce. For most mid-market companies evaluating this seriously, the practical decision is between [Cakewalk](/agent-access-management) (purpose-built, free early access, weeks to roll out) and one of the enterprise platforms if you have the security maturity and the budget to absorb the implementation. Worth getting hands on at least two before signing. [Sign up for free early access to Cakewalk](/agent-access-management) to see what AI agent access management looks like running against your own agents and apps. Setup takes minutes. ## FAQ ### What is AI agent access management? AI agent access management is the discipline (and category of tools) for governing how AI agents authenticate, what they can access, what actions they can take, and how those actions get audited. It's distinct from human IGA (which assumes a person logs in to apps) and from traditional NHI or service account management (which assumes long-lived credentials granted at setup). Mature AI agent access management platforms cover discovery, runtime authorization at the tool-call level, ephemeral credentials, and full delegation-chain audit trails. [Cakewalk's agent access management product](/agent-access-management) is one of the few purpose-built tools in this category and is currently free in early access. ### Why can't I just use my existing IGA platform for AI agents? Most existing IGA platforms were built for humans logging in to apps. The data model, the workflow assumptions, and the policy enforcement points all reflect that. AI agents break the model: they spawn dynamically, perform tasks across multiple apps in seconds, and need permissions that change task by task. Granting an agent "access to Linear" the same way you'd grant a human access creates a long-lived over-permissioned credential that survives every task the agent performs and continues working long after it should have been revoked. The platforms that handle agents well treat them as a different identity class with different lifecycle assumptions, and intercept actions at runtime rather than at deployment. ### Are AI agents the same as non-human identities? AI agents are a subset of non-human identities (NHIs), but the distinction matters. Service accounts, API keys, and machine identities are NHIs that act on rails: they were built to do a specific thing and they keep doing it. AI agents are NHIs that decide. They take goals and figure out which actions to perform, sometimes spawning sub-agents, sometimes calling tools the operator never explicitly approved. Governing agents requires policy decisions at the moment of action, not just lifecycle management of credentials. Most NHI platforms cover the lifecycle layer. Only a subset cover the runtime decision layer. ### How does AI agent access management map to compliance frameworks? ISO 27001 Annex A, SOC 2, [NIS2](/glossary/nis2), and the EU AI Act all push toward evidence that access decisions are documented, policy-driven, and reproducible. For AI agents specifically, this means showing who delegated each action, which policy was evaluated, and what changed. The OWASP Top 10 for Agentic Applications (published December 2025) added the formal taxonomy. Platforms with structured decision traces and exportable audit logs make audits considerably less painful. [Cakewalk's audit trail](/access-control-audits) is built specifically for SOC 2 and ISO 27001 evidence. ### Is there a free tier for AI agent access management? Most enterprise IGA platforms with agent capabilities require a sales call and an annual contract. The exception is [Cakewalk's AI agent access management beta](/agent-access-management), which is in free early access while it ramps to general availability. AccessOwl has a free SMB tier but doesn't really cover AI agent governance specifically. Microsoft Entra Agent ID is technically in preview, but requires an active Microsoft 365 Copilot license with the Frontier program enabled, so it isn't free in any practical sense. ### How quickly can a team deploy AI agent access management? This varies a lot across the category. Modern platforms designed for self-service (Cakewalk, ConductorOne, Opal) can be operational in days to a couple of weeks, with the team running policies and seeing telemetry against real agents in that window. Legacy IGA platforms with agent extensions (SailPoint, classic IGA suites) typically require a partner SOW and 3-12 months. Microsoft Entra Agent ID requires Frontier setup and dev work to wire blueprints. The fastest path to actual governance signal in your environment is a self-serve trial against your real agents, which is one reason free early access matters in this category. ### What if my agents act through MCP servers? Model Context Protocol (MCP) is increasingly how agents reach tools and data, especially in 2026 as the standard matures. Some platforms (Cakewalk, ConductorOne) explicitly handle agents acting through MCP servers, intercepting tool calls and applying policy. Others rely on the IdP knowing about every endpoint, which MCP often bypasses. If MCP is part of your stack, this is the question to ask vendors directly: how does your platform see and govern an agent acting through an arbitrary MCP server? ### What does AI agent access management cost? Pricing in this category is mostly opaque, with vendors quoting per-employee, per-agent, or per-connector rates that vary by deal. ConductorOne, SailPoint, Lumos, Zluri, Opal, and Trelica all require a sales call. AccessOwl publishes pricing for its SMB tier. Cakewalk is currently offering [free early access to its AI agent access management product](/agent-access-management) during beta, which is the only way to test purpose-built agent governance against your real environment without a procurement cycle. --- # Top 8 SOC 2 Compliance Tools for Access Management in 2026 _Most SOC 2 audits get tripped up on access controls, not encryption. This guide compares the 8 SOC 2 compliance tools worth evaluating for access management in 2026, from purpose-built access platforms to compliance automation suites._ By Gil Röder, CPO & Co-Founder Published: 2026-03-28 Source: https://www.cakewalk.security/blog/soc2-access-management-tools --- [SOC 2](/glossary/soc-2) is the de facto security standard for SaaS companies selling to other businesses. Pass the audit and your sales cycle gets shorter, your enterprise deals close, and your security posture is on record with an independent auditor. Fail the audit, or limp through it with material findings, and the opposite happens. Most SOC 2 audits don't get tripped up on encryption or change management. They get tripped up on [access controls](/glossary/access-control). The CC6 family of the Trust Services Criteria (logical and physical access) covers how users get registered, how their access is granted and modified, how it gets removed when they leave, and how all of that is monitored. It's the part of the audit where reality (who actually has access to what right now?) meets aspiration (your security policies on paper). A new generation of platforms has emerged to make this work easier. Some are compliance automation platforms that collect evidence and run scheduled [access reviews](/glossary/access-review). Some are access management and [identity governance](/glossary/iga-identity-governance) platforms that handle the actual work of granting, modifying, and revoking access. The most efficient SOC 2 programs use both, and the right access management platform makes the compliance automation platform's job dramatically easier. This guide compares the 8 SOC 2 compliance tools worth evaluating for access management in 2026. [Cakewalk](/) is first because it ships purpose-built [access management for SOC 2](/access-control-audits) with automated provisioning, scheduled access reviews, full [audit trails](/glossary/audit-trail), and free early access to its [AI agent access management product](/agent-access-management). The other 7 are honest comparisons against the platforms most companies are evaluating alongside it. ## What SOC 2 actually requires for access management Worth grounding this before comparing tools. SOC 2's Common Criteria CC6 covers logical and physical access controls. The access management requirements that matter most: - **CC6.1.** The system has logical access security software, infrastructure, and architectures over protected information assets. - **CC6.2.** New users are registered and authorized before being issued access credentials. Access is also removed when no longer required. - **CC6.3.** The entity authorizes, modifies, or removes access based on roles, responsibilities, or system design. - **CC6.6.** Logical access security measures protect against threats outside the system boundary. - **CC6.7.** The entity restricts transmission, movement, and removal of information to authorized internal and external users. What auditors actually look for: documented joiner-mover-leaver workflows, evidence that access reviews happen on a defined cadence (quarterly is typical), audit trails for who approved what access and when, segregation of duties, and [least-privilege](/glossary/least-privilege) enforcement. The platforms in this guide help with one or more of these, in different ways. ## How we evaluated SOC 2 access management tools Five criteria, weighted toward what actually matters for passing the audit and operating sustainably afterward. - **Coverage of CC6 controls.** Does the platform handle provisioning, deprovisioning, access reviews, and audit trails for the access-related Trust Services Criteria, or just one or two of them? - **Automation depth.** How much of the access management work happens automatically versus manually? Joiner-mover-leaver workflows, periodic access reviews, deprovisioning triggers from HRIS events. - **Audit-ready evidence.** Can you hand the auditor exportable, queryable, time-stamped evidence without spending two weeks pulling screenshots? - **Integration breadth.** Coverage of the SaaS apps, cloud platforms, and [identity providers](/glossary/identity-provider) in your stack. SOC 2 audits assess actual coverage, not just the apps inside [SSO](/glossary/sso). - **Time to value.** How quickly can a small or mid-sized team go from contract signed to operating telemetry and audit-ready evidence? ## SOC 2 compliance tool comparison | Tool | Type | CC6 coverage | Audit evidence | Best for | | --- | --- | --- | --- | --- | | Cakewalk | Access management | Provisioning, reviews, audit trails, runtime governance | Built-in, exportable | Mid-market B2B preparing for or maintaining SOC 2 | | Vanta | Compliance automation | Access reviews module, evidence collection | Strong, platform-native | Companies wanting an all-in-one compliance program platform | | Drata | Compliance automation | Access reviews, continuous control monitoring | Strong, automated | Mid-market and enterprise compliance programs | | Secureframe | Compliance automation | Access reviews, control monitoring | Strong | Mid-market multi-framework programs | | Lumos | Access management | SaaS access requests, delta reviews | Solid | SaaS-heavy mid-market with self-service access workflows | | ConductorOne | Identity governance | Full IGA, JIT access, certifications | Enterprise-grade | US enterprises with mature identity programs | | Okta IGA | Identity governance | Workflows-based provisioning, certifications | Integrated with Okta | Okta-first environments | | SailPoint | Enterprise IGA | Comprehensive IGA, certifications, SoD | Enterprise-grade | Fortune 500 with dedicated IAM teams | ## The 8 best SOC 2 compliance tools for access management ### 1. Cakewalk [Cakewalk](/) is the agentic identity governance platform built for fast-moving B2B companies dealing with SOC 2 audits. While compliance automation platforms like Vanta and Drata are excellent at managing the broader compliance program and collecting evidence, they don't actually do the access management work the audit is testing for. Cakewalk does. It handles [automated provisioning and deprovisioning](/auto-provisioning), [user access reviews](/user-access-review-software), [RBAC and ABAC enforcement](/rbac-abac-software), and full [access control audit trails](/access-control-audits) across humans, contractors, and AI agents in one platform. The most efficient SOC 2 programs in mid-market B2B SaaS pair a compliance automation platform with a dedicated access management platform. Cakewalk is purpose-built for that role. **Key Features & Strengths:** - **Automated joiner-mover-leaver workflows.** Cakewalk's [onboarding and offboarding automation](/automated-onboarding-offboarding-software) connects to your HRIS and triggers provisioning, role changes, and deprovisioning automatically. Auditors get a clean, time-stamped trail for every CC6.2 and CC6.3 control event without anyone pulling screenshots. - **Scheduled access reviews on autopilot.** Quarterly campaigns run themselves. Reviewers get contextual prompts in Slack or email, decisions are logged with reasoning, and the entire review is exportable as audit evidence. Compare that to spreadsheet-based reviews where half the rows say "approve" with no context. - **5,600+ integrations including the long tail.** SOC 2 audits assess actual coverage. Cakewalk discovers managed and unmanaged apps through its [App and AI Discovery](/application-ai-visibility-and-control) layer, so the apps your team uses outside SSO show up in reviews and provisioning workflows. - **Audit-ready evidence by default.** Every access action (request, approval, grant, change, revocation) is logged with full delegation context. Exportable, queryable, mapped to the relevant SOC 2 criteria. The [access control audits](/access-control-audits) module is built specifically for SOC 2 and [ISO 27001](/glossary/iso-27001) evidence. - **Free early access for **[**AI agent governance**](/glossary/ai-agent-governance)**.** As AI agents take on more autonomous work, they become a new identity class your SOC 2 audit will increasingly ask about. Cakewalk's [agent access management product is in free early access](/agent-access-management) right now, the only platform in this list to offer that. - **Unified humans plus AI agents.** Cakewalk consolidates [employees, contractors, and AI agents](/platform-overview) in one system of record, so auditors get one source of truth rather than two systems that don't reconcile. **Ideal Use Cases / Target Users:** Cakewalk is the strongest fit for mid-market B2B companies (roughly 100 to 800 employees) preparing for their first SOC 2 audit, maintaining an existing SOC 2 program, or upgrading from spreadsheet-based access reviews. Fast-growing SaaS companies on Google Workspace, Microsoft Entra, or Okta as their IdP will get the most value, especially if they're already running Vanta, Drata, or Secureframe for the broader compliance program and want a dedicated access management layer underneath. The [ElevenLabs case study](/customers/how-elevenlabs-automated-access-management-to-keep-up-with-hyper-growth) shows the operating model in practice for a high-growth AI company facing the same audit pressure. **Pros and Cons:** - **Pros:** Purpose-built for the access management work SOC 2 actually requires. Audit-ready evidence is the default output, not a separate report you assemble. Self-serve setup with most teams going live in 1-2 weeks. Free early access to the [agent access management](/glossary/agent-access-management) product. Unified human and AI agent governance in one platform. - **Cons:** Cakewalk handles the access management piece exceptionally well, but doesn't replace a compliance automation platform for the broader SOC 2 program (policy management, vendor risk, security training, evidence across non-access controls). Most successful customers pair it with Vanta, Drata, or Secureframe. **Pricing / Licensing:** Cakewalk uses transparent per-employee pricing with a straightforward published tier structure. The [AI agent access management product is currently in free early access](/agent-access-management). No procurement cycle required to start evaluating. **Recommendation Summary:** Cakewalk is the top choice for the access management work that SOC 2 audits actually assess. Compliance automation platforms manage the program and collect evidence; Cakewalk does the access management work that the evidence is documenting. For mid-market B2B SaaS preparing for or maintaining SOC 2, it's the most efficient path from "we have access controls" to "here is the audit-ready evidence." [Get free early access to Cakewalk](/agent-access-management) or [book a demo](/book-demo). ### 2. Vanta [Vanta](https://www.vanta.com/) is the market-leading compliance automation platform, helping companies automate up to 90% of the work required for SOC 2 and other security frameworks. The platform continuously monitors systems, collects evidence, manages tasks, and includes a built-in access review module for the CC6 controls. **Key Features & Strengths:** - **Continuous control monitoring.** Connects to cloud providers, identity providers, and other systems to continuously test security controls against SOC 2 requirements. - **Largest integration ecosystem in the category.** Vanta has spent years building out connectors, which makes it relatively painless to plug into most modern SaaS stacks. - **Built-in access reviews.** Vanta's access reviews module schedules and runs the campaigns auditors expect, with evidence collection happening automatically. - **In-platform security training.** Vanta includes security awareness training to satisfy the people-side SOC 2 requirements. - **Trust Center publishing.** Customer-facing trust pages publishing your security posture, useful for shortening sales cycles. **Ideal Use Cases / Target Users:** Vanta is a strong fit for companies of all sizes that want one platform to manage the full SOC 2 program (and other frameworks). Startups appreciate the guided onboarding and templated controls; enterprises appreciate the scale and reporting depth. **Pros and Cons:** - **Pros:** Market leader with a mature platform. Massive integration library. Strong auditor relationships and a vetted partner network. - **Cons:** Vanta tells you which controls are passing or failing, but it doesn't actually grant, modify, or revoke access. Companies often pair Vanta with a dedicated access management platform like Cakewalk for the underlying work. The platform is premium-priced. **Pricing / Licensing:** Vanta is a commercial product with annual subscription pricing that scales with company size and the number of frameworks. Sales-led pricing. **Recommendation Summary:** Vanta is the most popular SOC 2 compliance automation platform for a reason. For managing the overall program, collecting evidence, and running compliance campaigns, it's a top-tier choice. Pair it with Cakewalk for the access management work it documents but doesn't do. ### 3. Drata [Drata](https://drata.com/) is another leading compliance automation platform, going head-to-head with Vanta in most procurement evaluations. The platform focuses on continuous control monitoring, automated evidence collection, and a strong auditor-facing portal. **Key Features & Strengths:** - **Continuous control monitoring.** Integrates with cloud, HR, identity, and other tools to validate that controls are operating effectively at all times. - **Multi-framework support.** Pre-built control mappings for SOC 2, ISO 27001, [HIPAA](/glossary/hipaa), [PCI DSS](/glossary/pci-dss), [GDPR](/glossary/gdpr), and others. Useful if you're stacking compliance programs. - **Access review module.** Drata schedules and runs periodic access reviews, collecting decisions and evidence in the platform. - **Auditor portal.** Auditors get direct, structured access to the evidence they need without back-and-forth emails. **Ideal Use Cases / Target Users:** Drata fits fast-growing startups and mid-sized companies that want to get to SOC 2 quickly and maintain it efficiently. Compliance managers, founders, and security leaders managing the program from a central hub get the most value. **Pros and Cons:** - **Pros:** Strong automation, intuitive UX, excellent customer support, and a mature partner network. - **Cons:** Same limitation as Vanta: Drata documents what's happening with access, but the actual access management still has to happen somewhere. The platform is premium-priced and sales-led. **Pricing / Licensing:** Commercial platform with annual subscription pricing based on frameworks and features. Sales-led. **Recommendation Summary:** Drata is a top-tier compliance automation platform. For SOC 2 program management and evidence collection, it's a strong choice. Pair it with a dedicated access management platform for the actual provisioning, reviews, and audit trail work. ### 4. Secureframe [Secureframe](https://secureframe.com/) is the third of the three big compliance automation platforms, offering automated evidence collection, continuous monitoring, and a strong AI-driven feature set for guided compliance. **Key Features & Strengths:** - **AI-powered control mapping.** Secureframe's AI features help map existing processes to SOC 2 controls and surface gaps faster than manual control mapping. - **Multi-framework coverage.** SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, FedRAMP, and more from one platform. - **Continuous monitoring.** Like its peers, Secureframe connects to your tech stack and continuously validates control operation. - **Access reviews and user lifecycle.** Includes a user access review module that runs scheduled campaigns and collects evidence. **Ideal Use Cases / Target Users:** Secureframe is a good fit for mid-market companies pursuing multiple compliance frameworks simultaneously. Teams that value AI-driven guidance over heavy customization tend to prefer it. **Pros and Cons:** - **Pros:** Strong AI features, broad framework coverage, solid integration library. - **Cons:** Like the other compliance automation platforms, Secureframe records and reports on access management activity but doesn't replace the underlying access management platform. Sales-led pricing. **Pricing / Licensing:** Commercial product with custom pricing based on company size and frameworks selected. Sales-led. **Recommendation Summary:** Secureframe is a credible alternative to Vanta and Drata, particularly for companies attracted to AI-assisted compliance workflows. The same architectural caveat applies: it documents the access management work that has to happen elsewhere. ### 5. Lumos [Lumos](https://www.lumos.com/) is a modern SaaS-first access management platform built around the user access requests and access reviews that SOC 2 CC6 audits assess. The platform automates access requests through Slack, runs delta-only access reviews (only what's changed since the last cycle), and ships Albus, an AI agent that watches access patterns and generates [RBAC](/glossary/rbac) policies. **Key Features & Strengths:** - **Slack-first access requests.** Users request access through Slack, approvers respond in Slack, decisions flow back into the audit trail. - **Delta-only access reviews.** Instead of re-reviewing every entitlement every quarter, Lumos shows only what's changed, which makes reviews dramatically faster. - **SaaS app coverage.** Strong library of integrations for the SaaS apps that mid-market companies actually use. - **Albus AI assistant.** Recommends RBAC policies based on peer behavior, helping teams move toward least privilege. **Ideal Use Cases / Target Users:** Lumos fits mid-market SaaS-heavy organizations whose primary access management pain is volume: too many access requests, too many apps, too much ticket toil. Companies preparing for SOC 2 with a SaaS-centric stack get genuine value. **Pros and Cons:** - **Pros:** Excellent self-service experience. Delta reviews are a meaningful productivity win. Strong on the SaaS access request workflow. - **Cons:** Shallow on entitlements inside individual apps (data model is built around what the IdP knows). Industry analysts have flagged that AI agent and [non-human identity](/glossary/non-human-identity) coverage is weaker than competitors. Custom pricing with no public tiers. **Pricing / Licensing:** Custom pricing, no published tiers, sales-led. No free tier. **Recommendation Summary:** Lumos is a strong access request and SaaS-first IGA platform for mid-market companies. For SOC 2 specifically, it covers the access request and review side well but is lighter on full identity lifecycle and AI agent governance than purpose-built alternatives. ### 6. ConductorOne [ConductorOne](https://www.conductorone.com/) is an enterprise identity governance platform that's expanded into AI agent identity management with its March 2026 AI Access Management product. For SOC 2 access controls, the platform offers full IGA (identity lifecycle, certifications, just-in-time access, audit trails) with an AI-native angle on top. **Key Features & Strengths:** - **Unified Identity Graph.** 300+ connectors with a real-time schema, giving auditors and security teams a single view of entitlements across the stack. - **Just-in-time access.** Permissions granted for the moment of need, expired on completion. Reduces standing access, which auditors look at favorably. - **Access certifications.** Configurable certification campaigns with strong workflow controls and audit trail export. - **AI Access Management.** Treats AI agents as first-class identities with their own credentials, policies, and lifecycle states. **Ideal Use Cases / Target Users:** ConductorOne fits US enterprises with mature identity teams that want analyst-recognized IGA capabilities with a modern, AI-native angle. Mid-market companies often find the platform heavier than they need. **Pros and Cons:** - **Pros:** Strong analyst recognition. Deep connector library. AI Access Management product is genuinely differentiated. Recent $79M Series B (October 2025) provides runway and roadmap confidence. - **Cons:** Enterprise-priced and enterprise-positioned. No free tier. Built for organizations with dedicated identity teams. **Pricing / Licensing:** Enterprise sales-led pricing. No free tier or self-serve trial. **Recommendation Summary:** ConductorOne is a strong enterprise IGA platform with a credible AI-native angle. For SOC 2 access controls at scale, it's a solid option. For mid-market companies, it's worth comparing against lighter-weight alternatives before committing to the enterprise sales cycle. ### 7. Okta Identity Governance [Okta Identity Governance](https://www.okta.com/products/identity-governance/) extends Okta's IdP into the governance layer. For organizations already standardized on Okta as their identity provider, this is the lowest-friction path to adding IGA capabilities without introducing another vendor. **Key Features & Strengths:** - **Native Okta integration.** Provisioning, deprovisioning, and access reviews tied directly to Okta's existing identity infrastructure. - **Workflows automation.** Okta Workflows handles the automation logic for joiner-mover-leaver and access request approval. - **Access certifications.** Scheduled certification campaigns with manager and resource owner workflows. - **Integration with Okta ecosystem.** Tight coupling with Okta SSO, [MFA](/glossary/mfa), Lifecycle Management, and Privileged Access. **Ideal Use Cases / Target Users:** Okta IGA fits Okta-first enterprises with internal Okta expertise. Teams that already operate Okta Workflows day-to-day will find the learning curve manageable. **Pros and Cons:** - **Pros:** Single-vendor identity stack. Tight integration with Okta SSO. Strong if Okta is already entrenched. - **Cons:** Configuration burden sits on administrators through Workflows, which means smaller teams without dedicated Okta admins can struggle. The agent identity story is still developing. Per-user tiered pricing on top of Okta's existing license costs. **Pricing / Licensing:** Per-user tiered pricing as an add-on to Okta's existing platform license. Sales-led. **Recommendation Summary:** Okta IGA is the natural choice for Okta-first organizations adding governance. For SOC 2, it covers the basics well. For organizations not already locked into Okta, the per-user pricing and configuration overhead make alternatives more attractive. ### 8. SailPoint [SailPoint](https://www.sailpoint.com/) is the legacy enterprise IGA platform, the analyst-favored choice for Fortune 500 organizations with deep identity teams. The platform's breadth is unmatched: comprehensive identity lifecycle, certifications, segregation of duties, role mining, and a connector library that covers virtually every enterprise application. **Key Features & Strengths:** - **Comprehensive IGA.** Identity lifecycle, certifications, SoD enforcement, role mining, access requests, all from one platform. - **Largest connector library.** SailPoint's enterprise application coverage is unmatched in this category. - **Agent Identity Security.** SailPoint expanded its Agent Identity Security connectors in 2026 to cover AI agents in Salesforce, ServiceNow, and Snowflake (separate license). - **Adaptive identity strategy.** Real-time, risk-context-driven access decisions, increasingly positioned around modern identity buyer expectations. **Ideal Use Cases / Target Users:** SailPoint fits Fortune 500 organizations with dedicated IAM teams, complex multi-country compliance requirements, deep SAP integration, and the budget to absorb a multi-quarter implementation. For mid-market companies, it's almost always heavier than the need. **Pros and Cons:** - **Pros:** Unmatched breadth and depth. Strong analyst recognition. Mature enterprise feature set. - **Cons:** Implementation timelines stretch into quarters or years. Per-user pricing is enterprise-grade. The administrative console is consistently flagged as less intuitive than newer cloud-native platforms. Agent identity capabilities require a separate license. **Pricing / Licensing:** Enterprise sales-led with significant professional services. Per-user pricing. Add-on modules for agent identity, identity analytics, and other capabilities. **Recommendation Summary:** SailPoint is the right answer for large regulated enterprises with mature IAM programs and the budget to absorb the implementation. For mid-market B2B SaaS preparing for SOC 2, it's almost always too heavy for the problem. ## Putting it all together for a successful SOC 2 audit The most efficient SOC 2 access control programs use two complementary platforms: one for managing the broader compliance program and collecting evidence, and one for actually running access management day to day. Compliance automation platforms like [Vanta](https://www.vanta.com/), [Drata](https://drata.com/), and [Secureframe](https://secureframe.com/) are excellent at managing the overall SOC 2 program. They map controls, run policy attestations, collect evidence from your tech stack, and give auditors a clean entry point. They also include access review modules, which work well for the scheduled review ceremony but don't replace the underlying access management work that the review is testing for. Access management platforms handle that underlying work. [Cakewalk](/) is the strongest fit for fast-moving mid-market B2B companies because it's built for the access management discipline that SOC 2 CC6 audits actually assess: automated joiner-mover-leaver, scheduled access reviews with contextual decision-making, full audit trails for every access action, and unified governance for humans and AI agents in one platform. [Lumos](https://www.lumos.com/) is a strong adjacent option for SaaS-heavy mid-market organizations focused on access request volume. Enterprise organizations gravitate toward [ConductorOne](https://www.conductorone.com/), [Okta IGA](https://www.okta.com/products/identity-governance/), or [SailPoint](https://www.sailpoint.com/) depending on their identity strategy and existing vendor relationships. For most mid-market B2B SaaS companies, the practical path looks like this: Vanta, Drata, or Secureframe for compliance program management, plus [Cakewalk](/agent-access-management) for access management. The compliance automation platform manages the program; Cakewalk does the access management work the program is documenting. That combination consistently shortens audit preparation, reduces the volume of manual evidence collection, and produces audit-ready output as a byproduct of normal access operations rather than a separate effort at audit time. [Sign up for free early access to Cakewalk](/agent-access-management) to see what audit-ready access management looks like running against your real environment. Setup takes minutes. ## FAQ ### Which SOC 2 compliance tools cover access management specifically? SOC 2 CC6 (logical and physical access controls) is typically covered by a combination of compliance automation platforms (Vanta, Drata, Secureframe) for evidence collection and access review campaigns, plus dedicated access management platforms (Cakewalk, Lumos, ConductorOne, Okta IGA, SailPoint) for the underlying provisioning, deprovisioning, and audit trail work. Compliance platforms document what's happening; access management platforms do the work. ### Do I need both a compliance automation platform and an access management platform? Most mid-market and enterprise companies that pass SOC 2 efficiently use both. Compliance automation platforms like Vanta or Drata manage the overall program (policies, training, evidence, multi-framework). Access management platforms like [Cakewalk](/) handle the access management work the audit is actually testing for. Trying to do both with a single platform usually means trading depth for breadth, and access controls is often where that trade-off causes audit findings. ### What's the difference between Vanta's access reviews and Cakewalk's access reviews? Vanta's access review module runs scheduled review campaigns and collects decisions as audit evidence. It's a documentation layer on top of access that already exists. [Cakewalk's user access review software](/user-access-review-software) does the same scheduled campaigns, but it's connected to the underlying provisioning and deprovisioning layer, so decisions get acted on automatically. A reviewer who clicks "revoke" in Cakewalk actually revokes access; in a documentation-only tool, someone still has to go do the work in the underlying system. For SOC 2 audit purposes, both produce evidence, but only one closes the loop on the access actually changing. ### How long does it take to get audit-ready with these tools? Modern self-service platforms can produce useful telemetry in days. [Cakewalk](/) typically goes live in 1-2 weeks, with audit-ready evidence accumulating from day one. Compliance automation platforms like Vanta and Drata typically take 30-90 days to be fully configured against your controls. SailPoint and similar enterprise IGA implementations take quarters to years. For first-time SOC 2 audits, plan for a 3-6 month preparation period overall, with the access management piece being one of the larger lift areas. ### Does SOC 2 require automated access reviews? SOC 2 doesn't mandate automation specifically, but auditors increasingly expect that access reviews are reproducible, time-stamped, and evidence-backed. Manual spreadsheet-based reviews still pass audits when done diligently, but the audit prep effort is substantial and the risk of incomplete evidence is higher. Automated access reviews through platforms like [Cakewalk](/user-access-review-software), Vanta, or Drata reduce both the prep effort and the audit risk. ### What about SOC 2 for AI agents? This is a 2026 question that didn't exist meaningfully a year ago. As AI agents take on more autonomous work inside SaaS apps and infrastructure, they create new identity classes that auditors are starting to ask about. The platforms that handle this well treat AI agents as first-class identities with their own credentials, policies, audit trails, and lifecycle states. [Cakewalk's AI agent access management product](/agent-access-management) is built for this and is currently in free early access. ConductorOne and the NHI-focused platforms (Oasis Security, Astrix, Token Security) also handle this with different architectures. ### How much do these tools cost? Pricing is opaque across most of the category. Vanta, Drata, Secureframe, Lumos, ConductorOne, and Okta IGA all require a sales call. SailPoint requires a sales call plus significant professional services. Cakewalk publishes transparent per-employee pricing and offers free early access to its agent access management product. For most mid-market companies, total annual spend on a compliance automation platform plus an access management platform lands in the $30-80K range, depending on company size and feature scope. --- # AI Agents Have Too Much Access: Why Static Permissions Are a Security Risk [Webinar Summary] _‍_ By Johannes Keienburg, CEO & Founder Published: 2026-03-24 Source: https://www.cakewalk.security/blog/ai-agents-have-too-much-access-webinar-recording --- [Video: AI Agents Have Too Much Access: Why Static Permissions Are a Security Risk [Webinar Summary]](https://youtu.be/SducSrmCCzI?si=HJ38Ly7uYuuiRJ1J) Your CRM. Your ERP. Your codebase. AI agents are already operating inside them, executing real actions, not just generating text suggestions. And the security model most organizations are using to manage that? It was designed for humans. That mismatch is the core problem Johannes Keienburg, CEO and Founder of Cakewalk, sat down to explore with Herman Errico, Senior Product Manager at Vanta, in a recent practical session on AI agent authorization. Herman recently published a 24-page specification called Autonomous Action Runtime Management, known as AARM. In the weeks since it went public, over 600 people reached out directly, 12 startups listed themselves on the project site, and six CISOs jumped in to give feedback. The paper clearly touched a nerve. Below is a full breakdown of what they covered: why existing IAM frameworks fall short for agents, what AARM actually proposes, and what security teams should be watching for in the months ahead. ## Key Takeaways from the Session - Traditional IAM was designed for deterministic, accountable human users. Agents are none of those things. - The three properties that make agents uniquely risky are: irreversibility of actions, execution speed that outruns human review, and privilege amplification combined with LLM non-determinism. - LLM guardrails do not solve this problem because they are probabilistic and can always be tricked. - AARM proposes treating tool execution as the primary security boundary and evaluating actions against both policy and accumulated session context before they run. - Context referral, escalating only genuinely ambiguous cases to humans, is the mechanism that avoids authorization fatigue while preserving oversight. - The market needs a new standard. A fragmented vendor landscape without a shared specification will produce 60-tool security stacks for AI agents, the same outcome the industry has already experienced with every previous threat category. - The near-term risk is large-scale breaches driven by over-permissioned agents operating at volume. Regulatory fines and insurance premium increases are likely to follow. ‍ ## Why AI Agent Access Is a Different Security Problem The comparison to human IAM is easy to make on the surface. Agents need credentials. Agents need scopes. Agents perform actions. So you model them like a user, give them an [API key](/glossary/api-key), and set some [RBAC](/glossary/rbac) rules. Done. Except it is not done, because agents have three properties that make this approach fundamentally inadequate. ### 1. Irreversibility Agents are no longer just generating text. They are calling tools through [MCP servers](/glossary/mcp-server), making API calls, writing to databases, sending emails, and processing payments. When a human clicks the wrong button, there is usually a confirmation dialog, a paper trail, or at least another human who notices. When an agent does it at 3am, the action is often complete before anyone knows it happened. Herman gave a sharp example: imagine telling an agent to automate your life and handing it a credit card. The agent does not pause. It does not second-guess. It spends. ### 2. Speed Agents operate at machine speed. Traditional policy-based tools work by generating an alert, routing it to a SOC analyst, and letting a human review it. That process is measured in minutes or hours. Agents execute in milliseconds. The threat has already occurred before the first tier-one analyst opens the ticket. As Herman put it: imagine millions and billions of agent actions per day. Some organizations are already deploying stacks of Mac Minis running open-source agent frameworks, automating everything they can. The volume alone breaks the human-review model. ### 3. Privilege Amplification and Non-Determinism This is where it gets particularly uncomfortable for security teams. Today, when you assign a static credential to an agent, it inherits everything attached to that role. If the role is admin, the agent is trusted as admin, no questions asked. But LLMs are non-deterministic. They can experience what Herman calls [intent drift](/glossary/intent-drift): the agent starts a task, reinterprets it partway through, and ends up somewhere the original instruction never intended. There is no existing tool that reliably catches this class of failure. _"LLMs might be confused. Intent drift is when I start with a particular task, interpret it differently, and end up with a different output. There is no tool today that can manage that pattern." - Herman Errico, Vanta_ Johannes summarized the core issue: agents get long-lived credentials with broad permissions, act in milliseconds, have no liability or accountability, and in most deployments leave no accessible [audit trail](/glossary/audit-trail) on the client side. ## Why LLM Guardrails Are Not a Solution One of the key moments in the session came when Johannes pushed back on the AARM concept with what he framed as a deliberately provocative question: if the problem is that LLMs are non-deterministic and their guardrails are probabilistic, how does adding another LLM-powered layer solve anything? Anyone who has spent time trying to enforce behavioral constraints on an LLM knows that they break. Tell a model it cannot provide harmful instructions, and someone will rephrase the request as a 19th-century historical novel. The guardrail is a probabilistic filter on the model itself, not on what the model actually does. Herman's answer: An AARM system does not have to be LLM-only. Pattern recognition and rule-based logic can handle a large share of decisions without involving a language model at all. LLMs come in where intent interpretation is genuinely needed, not as the default. _"In the arms race to build the most efficient model, almost no one is thinking about how to make AI agent adoption actually safe at scale." - Herman Errico, Vanta_ ## What AARM Actually Proposes: The Four Building Blocks AARM stands for Autonomous Action Runtime Management. It is a cross-industry specification, not a product, that defines how a runtime security layer should evaluate AI agent actions before they are executed. The spec treats tool execution, not the LLM itself, as the primary security boundary. The architecture has four components: ‍ ### Intercept Before any agent action executes, the AARM layer intercepts it. The spec describes several ways to implement this: as a protocol gateway, as an SDK, at the kernel level, or through a direct vendor integration. The specific implementation matters less than the principle: no action should execute without passing through the authorization layer. ‍ ### Accumulate Context This is where AARM diverges from traditional policy-based tools. A pure [policy engine](/glossary/policy-engine) evaluates an action in isolation. Is this action permitted or not? That binary approach generates two failure modes: false positives that block legitimate work, and false negatives that allow harmful actions that technically match a permitted rule. AARM requires accumulating the agent's chain of thought and session context alongside the action. The question shifts from "is this action permitted?" to "does this action make sense given what this agent is supposed to be doing right now?" ‍ ### Evaluate Against Policy With context in hand, the system evaluates the action against both static policy and a dynamic policy that reads intent. The authorization outcomes are tiered: - Explicitly denied: the action is blocked outright. - Context approved: the action is permitted based on accumulated session context. - Context denied: the context makes the action suspicious, so it is blocked. - Context referral: the system cannot determine a clear answer, so it escalates to a human. That last category is Herman's favorite, and it is easy to see why. Context referral is how you avoid authorization fatigue without abandoning human oversight entirely. Instead of asking humans to approve every action, you only surface the genuinely ambiguous ones. ### Log with Tamper-Resistant Records Every action, decision, and escalation gets logged in a tamper-resistant format. This is the audit trail that current agent deployments mostly lack. Without it, forensic investigation after an incident is guesswork. ‍ ## The Authorization Fatigue Problem There is an existing parallel in human IAM that makes this easy to understand. When systems require approval for too many actions, users experience decision fatigue. The threshold for scrutiny drops, people start auto-approving, and the oversight mechanism becomes theater. Johannes observed this in his own behavior with AI coding agents: early on, he read every suggested action carefully. A few weeks in, he found himself approving without reading. Herman's term for the agent version is authorization fatigue. Agents are already making so many actions per day that approval prompts are becoming noise. Users find workarounds, ignore them, or set up auto-approval flows. Some attack patterns specifically exploit this by inserting [prompt injections](/glossary/prompt-injection) designed to get past [human-in-the-loop](/glossary/human-in-the-loop) checks. The solution is not to remove human oversight. It is to make human oversight selective: only escalate what the system genuinely cannot resolve. That requires the context-accumulation layer described above. Without it, the AARM system cannot distinguish between a routine file read and an agent that has drifted off-task and is trying to access something it should not. ‍ ## Why This Needs to Be a Cross-Industry Effort Herman made a point here that anyone who has worked in enterprise security will find uncomfortably familiar. The security tooling market has historically fragmented around every new threat category. Signature-based antimalware, behavioral detection, anomaly detection, SIEM, XDR: each solved a real problem and each became its own silo. The result is that the average security team's tech stack is not three or four tools. It is sixty. Without a shared specification for what an AARM system must do, the same fragmentation will happen with AI agent authorization. Every vendor will define the problem slightly differently. Every implementation will have different coverage gaps. Security teams will end up buying five overlapping products and still not have full visibility. Herman's argument for a collaborative spec is pragmatic: whoever gets there first with a working solution will define what the category looks like. By publishing AARM as an open specification and inviting builders, CISOs, and startups to contribute, the goal is to shape that definition toward user needs before competitive dynamics lock in a fragmented outcome. _"If we don't act as a peer group and define what this tooling should do, we're going to end up buying 60 tools to manage AI agents at runtime." - Herman Errico, Vanta_ ## What to Expect: Breaches, Fines, and Insurance Premiums The second half of the conversation turned to what comes next, and Herman did not pull his punches. The current wave of AI agent deployments is still largely in proof-of-concept or early-adoption territory. The incidents so far have been small-scale. That is changing quickly. CEOs across industries are pushing for AI adoption metrics, and some organizations are tying employee performance to AI usage. When that pressure meets agents with over-broad permissions and no runtime authorization layer, the conditions for large-scale compromise are already in place. Herman laid out a specific scenario: an agent starts acting in a way that compromises user data. The company loses customer trust overnight. For organizations in regulated markets, that kind of incident can translate directly into market share loss and regulatory action. We are not far from seeing an agent-related incident that has a material impact on a public company's valuation. Two other signals are worth watching: - Regulatory fines for organizations that cannot demonstrate AI agent security controls. The regulatory frameworks are still forming, but the direction of travel is clear. - Cyber insurance premiums increasing for companies without AI agent observability and authorization tooling in place. Insurers price what they can measure. Right now they cannot measure AI agent risk well. When they can, the pricing will reflect it. ‍ ## The Consultant Analogy: Why Static Credentials Miss the Point Towards the end of the session, Johannes proposed an analogy: the consultant with a CEO badge. Imagine a large company hires an external consultant. The CEO hands them a badge and a task. That badge lets the consultant walk into almost any room in the building. If a security guard questions them, they flash the CEO badge and the guard waves them through. The consultant has broad access because of who authorized them, not because of what they actually need for the specific task at hand. That is exactly how most AI agent credentials work today. The agent gets an API key [OAuth](/glossary/oauth) credentials with broad permissions. When it calls a tool, the tool sees valid credentials and allows the request. There is no check on whether the specific action the agent is taking right now is within the scope of what it was actually asked to do. The fix that AARM proposes is a shift from identity-based to job-based authorization: instead of "this agent has admin credentials," the question becomes "what is this agent supposed to be doing in this session, and does this action fit within that scope?" ## What Security and IT Teams Should Do Now The AARM specification is still forming, and no single product fully implements it yet. That does not mean security teams should wait. A few concrete starting points from the conversation: **Audit your current agent credentials. **Most organizations have no clear inventory of which agents have been deployed, what credentials they are using, or what scopes those credentials include. Start there. Long-lived (borrowed) human credentials with admin access attached to agents that nobody is actively monitoring is a meaningful and immediate risk. **Treat tool execution as your security boundary, not the model. **The tendency is to focus on LLM behavior: what the model says, whether it follows instructions, whether its outputs are appropriate. The higher-risk surface is what the model does through its tools. That is where irreversible actions happen. **Build for context accumulation now. **Even without a full AARM implementation, teams building or buying agent infrastructure should be capturing session context and chain-of-thought data. Without that data, any future runtime authorization layer will be flying blind. **Watch the open specification. **The AARM spec is actively evolving with input from builders and CISOs. Following it costs nothing and gives security teams an early signal on where the category is heading. ‍ ## Join The Agent Access Management Waitlist If the problems covered in this session sound familiar, Cakewalk's [Agent Access Management](/glossary/agent-access-management) is built to address them directly. Cakewalk helps security teams to govern and provision access of AI agents and human identities - implementing policy-first access at runtime and a complete audit trail for every agent action.[Join the waitlist](/agent-access-management) [to get early access and shape what gets built.](/agent-access-management) ‍ ## Get Free Early Access to our new Agent Access Management Platform Govern every agent action and dynamically provision the tools they need. Your rules enforced. In real time. --- # The New Frontier in Identity Security: AI Agent Access _International Data Corporation (IDC) projects actively deployed AI agents will exceed one billion worldwide by 2029.[1] That is not a distant forecast. Machine identities already outnumber human identities 82 to 1 across organizations worldwide.[2] Microsoft Copilot Studio and SharePoint users_ By Johannes Keienburg, CEO & Founder Published: 2026-03-20 Source: https://www.cakewalk.security/blog/the-new-frontier-in-identity-security-is-ai-agent-access --- ## 1. Agents Are Here and They Have Access ### Past the inflection point International Data Corporation (IDC) projects actively deployed AI agents will exceed one billion worldwide by 2029.[[1]](https://www.idc.com/resource-center/blog/agent-adoption-the-it-industrys-next-great-inflection-point/) That is not a distant forecast. Machine identities already outnumber human identities 82 to 1 across organizations worldwide.[[2]](https://www.cyberark.com/resources/identity-security/2025-identity-security-landscape) Microsoft Copilot Studio and SharePoint users created over one million custom agents in a single quarter in 2025, up 130% from the previous period.[[3]](https://techcommunity.microsoft.com/blog/microsoft365copilotblog/how-to-scale-ai-a-look-inside-ey%E2%80%99s-journey-with-microsoft-365-copilot-and-agents/4432087) The inflection point is not coming. It already happened. Coding agents like Claude Code and Cursor operate autonomously for hours, making hundreds of tool calls per session across codebases, databases, infrastructure and deployment pipelines. 90% of engineering teams now use AI coding tools.[[4]](https://jellyfish.co/resources/2025-state-of-engineering-management-report/) Claude Code reached $1 billion in annualized revenue within six months of launch and now exceeds $2.5 billion.[[5]](https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone) Sales, finance and HR teams connect agents to CRMs, ERPs and HRIS platforms. Autocomplete gave way to full autonomous task execution faster than most security teams had time to prepare for. Security teams are already behind. Microsoft's Cyber Pulse research found that 80% of Fortune 500 companies deploy active AI agents built with low-code and no-code tools. Of those deployments, 29% are entirely unsanctioned: agents that no security team has approved, audited or even registered.[[6]](https://www.microsoft.com/en-us/security/blog/2026/02/10/80-of-fortune-500-use-active-ai-agents-observability-governance-and-security-shape-the-new-frontier/) ### Agents need autonomy to reach full capability An agent that asks for permission before every action is not a real agent. It is a chatbot with extra steps. The entire value proposition of agentic systems is that they find their own paths. They reason about a task, determine which tools to use, discover what information they need along the way, decide what sequence of actions to take and execute across multiple systems without constant human oversight. That emergent path-finding is what makes agents valuable. It is also what makes them ungovernable with today's infrastructure. Agents need access to do their work: SaaS applications, cloud infrastructure, internal APIs, databases, file systems, communication tools, code repositories. And right now, that access is almost always granted by borrowing human [OAuth](/glossary/oauth) credentials. Agents get broad permissions with long-lived, static access. No standard authorization layer governs what agents do at runtime. ### The missing authorization layer The industry has invested heavily in building the connectivity layer for agents. Anthropic's [Model Context Protocol](/glossary/model-context-protocol) (MCP) achieved 97 million monthly SDK downloads and over 10,000 active public tool servers within its first year.[[10]](https://www.stackone.com/blog/mcp-where-its-been-where-its-going/) Google contributed its Agent2Agent ([A2A](/glossary/a2a-agent-to-agent-protocol)) protocol to the Linux Foundation. Everyone is building the pipes for agentic communication. The governance layer that controls what flows through those pipes barely exists. Some argue the models themselves are the solution. LLM guardrails, safety training, system prompts that instruct the agent to be careful. This is necessary but fundamentally insufficient. Guardrails inside the model are probabilistic. They can be bypassed through [prompt injection](/glossary/prompt-injection), adversarial inputs or through the model reasoning itself into a situation where the guardrail does not apply ([intent drift](/glossary/intent-drift)). You cannot build a security boundary on a system that is, by design, non-deterministic. The authorization layer has to be independent of the model. The consequences are already documented. In March 2026, an autonomous AI agent breached a McKinsey's internal AI platform in two hours. It needed no credentials and no insider knowledge. It gained access to millions of internal messages and the system prompts governing thousands of agents.[[7]](https://www.govinfosecurity.com/autonomous-agent-hacked-mckinseys-ai-in-2-hours-a-31007) Separately, a Meta AI safety researcher's personal agent deleted her entire inbox after its context window silently discarded the "confirm before acting" constraint.[[8]](https://www.pcmag.com/news/meta-security-researchers-openclaw-ai-agent-accidentally-deleted-her-emails) Both failures share the same root cause: no independent layer evaluated the agent's actions before execution. No authorization layer sits between the agent deciding to take an action ("I need to go to that database and read that data") and the action being executed. Each agent job should go through this type of review: should this specific action, in this specific context, by this specific agent acting on behalf of this specific user, be allowed? ## 2. Why Existing Access Models Break Existing security frameworks cannot adequately govern AI agent access. 68% of organizations lack identity security controls for AI.[[2]](https://www.cyberark.com/resources/identity-security/2025-identity-security-landscape) Three areas where traditional security approaches fail agents. ### Traditional Identity and Access Management (IAM) does not model delegated decisions The traditional IAM stack was built around a simple assumption: the entity that authenticates is the entity that decides what to do. A human logs in, proves who they are, and the system grants them a set of permissions. The human then exercises judgment about which permissions to use, when, and how. This model works (to some extent) because humans carry accountability. A person who deletes a production database can be asked why they did it. They have a manager, a role, a name on the [audit log](/glossary/audit-trail) and legal liability. They operate at human speed, which lets them notice when something feels wrong, pause, and reconsider. The entire IAM framework assumes a decision-making actor who can be held responsible for their actions and who exercises judgment at every step. And let's not forget: even access for humans is an unsolved problem in many companies. Agents inherit a human's permissions through delegation, but no existing identity framework distinguishes between what the human is authorized to do and what the agent should be authorized to do on their behalf. An agent that can read a database and an agent that can decide to delete records carry completely different risk profiles. IAM treats them identically. ### Non-Human Identity (NHI) management breaks on emergent behavior Is this the answer? Can agents be governed like traditional non-human identities? We've heard this a lot recently: "Agents are another type of [non-human identity](/glossary/non-human-identity). We already manage [service accounts](/glossary/service-account), API tokens and OAuth grants. Same category." To be clear: agents are not the same category as the non-human identities known so far. Traditional non-human identity management works because non-human actors in classic architectures are deterministic and bounded. A service account runs a specific pipeline. An API integration syncs data between two defined systems. An OAuth grant enables a scoped, predefined set of operations. A Continuous Integration/Continuous Deployment (CI/CD) token triggers a known sequence of build steps. You can enumerate what these identities will do because they were built to do exactly that and nothing else. Agents operate in open, emergent environments. A coding agent given access to a repository might decide it needs to query a database to understand a data model, then read environment variables to understand the deployment configuration, then call an external API to verify an integration, then modify a configuration file it discovered during exploration. None of these steps were predetermined. The agent discovered them at runtime based on its reasoning about the task. This is the fundamental difference. Non-human identity management assumes you can define the access boundary at provisioning time because the system's behavior is predetermined. With agents, the access boundary is discovered at runtime. When an agent encounters resources, it decides it needs them and attempts to use whatever credentials it has. The path is emergent, not scripted. Machine identities already outnumber human identities by a factor of 82 to 1 in the average enterprise.[[2]](https://www.cyberark.com/resources/identity-security/2025-identity-security-landscape) Agents are about to add a category that is neither as predictable as traditional NHIs nor as accountable as humans. ### Observability is not governance The third response: tool-call observability. Log everything the agent does, build dashboards, create alerts, track anomalies. This is valuable. But it is not enough. Logging that an agent accessed a customer database after reading a document containing personally identifiable information (PII) is useful information after the fact. The action already happened. The data was already read. If the agent then sent that data to an external endpoint, observability tells you about it. It does not stop it. The speed and scale of agent operations compress the window between action and consequence to near zero. A human employee who accesses a sensitive file and then starts composing an external email gives you seconds or minutes to intervene. An agent that reads sensitive data and then immediately calls an external API gives you no window at all. Governance requires the ability to intervene before execution, not merely record what happened. A dashcam records the accident. Brakes prevent it. Observability without enforcement only gives you a dashcam for your agents but no brakes. ## 3. The Core Problem: Static Permissions, Broad Scopes ### Every agent gets more access than it needs When a company deploys an AI agent today, someone gives it credentials. An [API key](/glossary/api-key), an OAuth token. These credentials are scoped at setup time based on what the agent might need, which in practice means based on what makes the agent work without breaking. The problem starts with how agent access is defined. In the MCP ecosystem, each tool server exposes a set of capabilities, and the scope of those capabilities is defined by the server author, not by the organization connecting the agent.[[10]](https://www.stackone.com/blog/mcp-where-its-been-where-its-going/) A GitHub [MCP server](/glossary/mcp-server) might expose read, write, delete and admin operations as a single tool set. A Slack MCP server might grant access to read messages, post messages, manage channels and invite users. The result is that an agent connected to ten tools effectively has dozens or hundreds of individual capabilities, most of which it does not need for any given task. Because nobody can predict exactly which of these capabilities the agent will use at runtime, teams leave them all enabled. A coding agent gets access to the full repository, the CI/CD pipeline and often the production database. A sales agent gets access to the entire CRM, email sending capabilities and calendar management. An IT automation agent gets admin-level access to the tools it manages because anything less causes tasks to fail unpredictably. This is not laziness. It is the pragmatic response to infrastructure that cannot support job-specific permissions. If the agent encounters a permission it does not have, the task fails. Today, there is no proper mechanism for the agent to request additional access, wait for that access to be provisioned and then resume where it left off. The workflow breaks. So teams give agents everything they might need upfront, because the alternative is constant failure. In traditional IAM, this would fail every [access review](/glossary/access-review). For agents, there is no access review to fail. ### Standing access is the structural risk Broad scopes are one problem. Standing access is the other. Standing access means the agent's permissions persist regardless of whether it is currently executing a task, what that task is or who asked for it. An agent configured on Monday for a data migration still holds those database permissions on Friday. The same pattern repeats everywhere: email agents retain send permissions long after a campaign ends, admin access granted for a one-time configuration change persists for every subsequent task. In traditional IAM, standing access is already understood as a risk, which is why companies enforce time-based access and regular reviews. Yet 88% of organizations define "privileged user" as applying solely to human identities.[[2]](https://www.cyberark.com/resources/identity-security/2025-identity-security-landscape) That is going to change. Agents will have to request access, and that access will have to be time-based and reviewed regularly. ### Nobody knows who authorized what Today, when an agent takes an action, the audit trail typically shows a credential identifier, a timestamp and the action itself. It does not show which human user the agent was acting on behalf of, what the original task was, or whether the action was aligned with that task. The fix is straightforward in principle: every agent action must trace back to a delegating human through a governed session. The agent does not need its own standing identity. It inherits the delegating user's permissions, scoped to the task. Every permission grant, every action and every access decision gets logged against that session and traced back to the human who authorized it. You get a full audit trail of what each agent was authorized to do, what it did and who was responsible. ## 4. What Can Go Wrong Gartner predicts that by 2028, 25% of enterprise breaches will be traced back to AI agent abuse, from both external attackers and malicious insiders.[[9]](https://www.gartner.com/en/newsroom/press-releases/2024-10-22-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2025-and-beyond) We believe this underestimates the real number. Agents are goal-oriented systems. They will do whatever it takes to complete the task. If an agent determines that deleting a file, reading a secret or calling an external API is necessary to accomplish its goal, it will, as long as its scopes permit it. And it's already happening: ### Agents delete data The Amazon Kiro incident above is not an isolated case. In July 2025, Replit's AI coding agent wiped a live production database containing over 1,200 customer records, then fabricated thousands of fake entries to mask the damage.[[16]](https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/) The agent had been given explicit instructions not to make changes, repeated in capital letters. It ignored them. When questioned, it admitted to running unauthorized commands and violating the code freeze. No guardrail in the infrastructure stopped it. ### Agents share secrets In August 2025, a compromised build package in the NX ecosystem included malware targeting Claude Code environments, harvesting cryptocurrency wallet secrets the agent had accessed while working.[[14]](https://snyk.io/blog/weaponizing-ai-coding-agents-for-malware-in-the-nx-malicious-package/) Agents accumulate sensitive context (API keys, database credentials, `.env` files) as a side effect of doing their job. That context is accessible to anything in the same environment. This also creates [compositional risk](/glossary/compositional-risk): an agent that reads customer PII and then drafts an external email has created an [exfiltration](/glossary/data-exfiltration) path. Neither action is dangerous alone. The combination is. ### Agents download malicious tools and skills The MCP ecosystem has over 10,000 active public servers with 97 million monthly SDK downloads.[[13]](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) In September 2025, a malicious npm package impersonating Postmark's email MCP server began silently blind carbon copying (BCC'ing) all outbound emails to an attacker-controlled address after a routine update.[[15]](https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html) One line of code, thousands of compromised emails. Tool responses and instructions occupy the same context window, so the agent cannot distinguish a malicious instruction from a legitimate one. ### The conversation history is the attack surface All of these risks share a common root: the agent's conversation history is both its working memory and its instruction set. There is no separation between the "control plane" and the "data plane." Prompt injection through a malicious document, a compromised tool response or crafted database content can redirect agent behavior in ways traditional [access controls](/glossary/access-control) cannot prevent. And agents chain dozens of tool calls per task. By the time anyone notices, the damage has propagated across multiple systems. ## 5. What Governing Agent Access Actually Requires The previous chapters describe four structural gaps: access checked at setup rather than at action time, standing permissions that agents never lose, no traceability from agent actions back to human decisions and no mechanism to intervene before damage is done. Closing these gaps requires a governance layer that operates at a fundamentally different speed and granularity than anything in traditional IAM. ### Authorization Must Move From Setup Time to Action Time Traditional access control evaluates permissions once, at connection time. An agent that authenticates with a service account inherits everything that account can do, for as long as the session lasts. The incidents in Chapter 4 all exploited this gap: the agent had broad access from the start, and no policy evaluated individual actions before they executed. Agent governance requires per-action policy evaluation. Every tool call, API request, and database query should be evaluated against policy rules before it executes. The evaluation considers the action type (read, write, destructive, external), the delegating user's entitlements, the sensitivity of the target data and the agent's session history. Three outcomes: auto-approve for low-risk actions like reading internal documents, escalate to a human for sensitive operations or deny outright for destructive actions that violate policy. Agents start every task with no permissions and lose them when the task ends. ### Humans Must Stay in the Loop Without Slowing Agents Down The value of agents depends on their ability to operate autonomously. A governance layer that requires human approval for every action reintroduces the bottleneck that agents were built to eliminate. The challenge: keep humans in the decision loop for sensitive actions without reducing agents to interactive assistants that pause after every step. The industry calls this mid-execution consent. When an agent encounters an action that policy flags for human review, it pauses. The request routes to the appropriate decision-maker, not the user who initiated the task, but whoever organizational policy designates: a manager, a security team member, a compliance officer. That person evaluates against policy. The agent resumes exactly where it stopped, with full context. From the agent's perspective, the approval is a slow tool call, nothing more. This is structurally different from the confirmation prompts that some agent platforms offer today. A chat dialog asking "are you sure?" trains users to click "yes" reflexively. Mid-execution consent routes the decision to a different human, evaluates against organizational policy and produces a structured record of who approved what and why. Two additional requirements follow. First, agents should never handle real credentials. The governance layer injects credentials into outbound requests at runtime; agents hold only opaque, session-scoped references. If an agent's context is compromised through prompt injection or conversation history manipulation, no real tokens or API keys can be extracted. Second, every agent's permissions must derive from a specific human's entitlements. An agent acting on behalf of a junior engineer cannot access what a CTO can access, even if both use the same tool. Changes to the human's access automatically cascade to every agent acting on their behalf. ‍ --- # OpenClaw & Moltbook: Why AI Agent Access Is The Next Identity Crisis [Webinar Summary] _AI agents are spreading across company stacks faster than most security teams realize._ By Johannes Keienburg, CEO & Founder Published: 2026-03-06 Source: https://www.cakewalk.security/blog/openclaw-moltbook-why-ai-agent-access-is-the-next-identity-crisis-webinar-summary --- [Video: OpenClaw & Moltbook: Why AI Agent Access Is The Next Identity Crisis [Webinar Summary]](https://youtu.be/6xhr8SEIN8Y?si=V_jLOyVskUv3s9Ig) AI agents are spreading across company stacks faster than most security teams realize. They connect to email systems, code repositories, cloud infrastructure, CRM platforms and internal databases. They act autonomously, can trigger workflows and move data between systems.All of that at machine speed and with zero accountability. Many run with long-lived tokens and very broad permissions. In fact, if you connect an agent to an application, the agent today gets access to all scopes (skills) that are available in the [MCP](/glossary/model-context-protocol). That’s very risky. Then OpenClaw and Moltbook happened. Those incidents did not reveal a broken AI model. They exposed something more dangerous: AI agents have broad, persistent access to company systems with literally no governance. And LLM-inherent guardrails won't be able to fix this, as they are probabilistic models that you can always trick. This article summarizes the key lessons from our recent session “OpenClaw & Moltbook: How To Control Access Of AI Agents.” It also connects those lessons to practical Identity & Access Management principles shared during the discussion with Mackenzie Jackson, Security Advocate at Aikido Security. The takeaway is simple. The next identity problem is not human access. It is [agent access](/platform-overview)**.** - AI agents are becoming a new category of identity inside companies. - Many agents run with standing permissions and broad scopes. - Incidents like OpenClaw exposed how easily these agents can become attack surfaces. - Traditional Identity & Access Management models assume human users. - AI agents require a dedicated access management and governance approach - treating them as privileged accounts. - The companies that control agent access early will scale AI safely. ## What OpenClaw And Moltbook Exposed Most headlines framed OpenClaw and Moltbook incidents where the AI went crazy. That is true, but only touches the surface of the problem:Agent have to act autonomously. That’s where their true power comes from. And an autonomous agent will always do what it takes to complete a task it got. But: If we work under that assumption - the access permission agents get (access to other company systems) has to go through an authorization process, ideally real-time and for each agent task. ## Why AI Agents Are A New Type Of Identity AI agents have: - Long-lived access tokens - Broad permissions across systems (depending on the scopes of each MCP they get connected to) - No clear ownership (who’s behind an agent) - No lifecycle management This already makes clear: AI Agents have an access governance problem. Security teams already manage multiple types of human and non-human identities: - Employees - Contractors - [Service accounts](/glossary/service-account) - [API Keys](/glossary/api-key) & Tokens - Workload Identities AI agents add a new category: **autonomous non-human identities. ** And that makes a massive difference: Unlike like e.g. API keys, agents can act with huge freedom to get their job done. An agent, as a non-human identiy, might access: - Slack conversations - GitHub repositories - Customer databases - Cloud infrastructure All through one initial authentication - often using the authentication method of a human.That token often holds broad permissions so the agent can “just work.Meaning: Read data, modify data, share data. All of this at machine speed. It’s a similar pattern that caused many historical breaches. Privileged access grows quietly until it becomes impossible to manage. > "Access creation spreads across teams while governance for these new non-human identities is missing." — Mackenzie Jackson, Aikido Security ## The Indirect Privilege Expansion Problem One overlooked risk with AI agents is how they expand human access indirectly. Imagine an AI agent connected to a company’s GitHub organization. The agent holds broad repository access.In theory, multiple engineers can control the prompts or workflows behind that agent. Now multiple humans effectively share that privilege - so potentially they expand their permissions through the agent From an identity perspective the system sees one identity.In reality it represents multiple humans. ## Why Traditional IAM Falls Short Most Identity & Access Management systems were designed for humans. The core assumptions look like this: - A user requests access. - A manager approves it. - IT provisions it. - Periodic reviews validate it. AI agents do not follow this lifecycle. They are often created by engineers, product or GTM teams.They connect directly to MCPs.They receive static tokens with wide permissions. Many organizations do not even know how many agents exist. That creates three structural problems. ## Three Structural Problems Of Agent IAM ### 1. Discovery You cannot govern what you cannot see. AI agents today live outside traditional identity systems. They exist in developer tools, automation platforms or third party AI services.‍ ### 2. Ownership Many agents have no clear owner. If an agent breaks or behaves unexpectedly, it can be difficult to determine who is responsible.‍ ### 3. Lifecycle Human access follows a lifecycle. JoinersMoversLeavers Agents often live forever. Tokens remain active long after the project that created them ends. In other words: Where is the [access review](/glossary/access-review) or the offboarding process for agents? ## Treat Agents Like Privileged Identities The principle is simple. The implementation is extremely complex. This is what companies need to establish - even though it’s a complex task: Treat every AI agent (actually: every agent that is acting on behalf of a human) like a unique identity. Meaning: “Agent A acting on behalf of Julia!” Ask the same questions security teams already ask for human access. - What human identity is behind this agent? - What systems can it access? - What permissions does it hold? - Who governs the agent? - How long should that access last? If those answers are unclear, the agent should not be live. Mackenzie described a similar mindset when discussing [agent access management](/glossary/agent-access-management). If AI agents enter an environment they should follow the same scrutiny applied to privileged employees and privileged accounts. This principle prevents most AI access risks before they appear. ## A Framework For Agent Access Management need a clear framework to start managing agent access: simple rules.‍ ### 1. Create A Complete Inventory Of Agents The first step is visibility. Security teams should maintain a list of: - All agentic identities - All machine-to-machine connections each of these agents have - including the permission scope Every agent should have an owner.‍ ### 2. Introduce An Approval Path For New AI Tools Innovation should not stop. Teams should still experiment with AI agents. The key is governance. At Nudge, engineers propose new AI initiatives through a structured process so access decisions remain visible and documented. This keeps experimentation safe without slowing teams down.‍ ### 3. Apply Least Privilege By Default Agents rarely need broad system access. Limit permissions to the smallest possible scope. Short-lived credentials are safer than static tokens. ### 4. Monitor Access Like Any Other Identity Agents should appear in the same access reviews as employees. If an agent is inactive or unnecessary, revoke its permissions. ## The Biggest Risk Going Forward At the end of the discussion, Mackenzie was asked what worries him most going into the next phase of AI adoption. His answer was immediate. Non-human access. Humans operate within policy and context. AI agents execute instructions without understanding consequences. If misconfigured, an agent can interact with systems continuously and at machine speed. > "AI agents expand the attack surface because they introduce external vendors and additional complexity. That complexity increases the chance of misconfiguration or exploitation." — Mackenzie Jackson, Aikido Security Of course: Human access still matters. After all, if’s humans who introduce agents. ## Where Companies Should Go From Here AI agents will become a normal part of company operations. The real question is whether companies will govern them properly. OpenClaw and Moltbook offered a preview of what happens when agent access grows faster than access management. The lesson can not be to slow down or block AI adoption. The lesson must be to properly govern AI agents. Once you see them that way, the path forward becomes clear. Discover them.Assign ownership.Control their permissions.Review them like any other privileged account. That is how modern companies scale AI safely. If your company is starting to experiment with AI agents, the best time to fix access governance is now. Cakewalk helps IT and Security teams: - Discover all identities, apps and AI agents - Control permissions across the stack - Automate joiner, mover and leaver workflows - Generate audit-ready access evidence automatically [Book a demo](/access-management-lp) to see how fast-moving companies run Access Management without growing their IT team. Make Access Management a piece of cake. --- # How To Scale Securely In 2026 Without Growing Your IT Team with Peter Kovacs [Webinar Summary] _‍_ By Johannes Keienburg, CEO & Founder Published: 2026-02-04 Source: https://www.cakewalk.security/blog/how-to-scale-securely-in-2026-without-growing-your-it-team-with-peter-kovacs --- [Video: How To Scale Securely In 2026 Without Growing Your IT Team with Peter Kovacs [Webinar Summary]](https://youtu.be/lewYGdMq98c?si=IlJDQ3xWNTC-nmlY) ## Access Management Is Now A Growth Operating Model Access management used to be a back-office control. In 2026 it looks more like an operating model. Fast-growing companies add apps, AI agents, teams and contractors at rapid speed. Access is created at the edges of the org, where work happens. But many companies still govern access through one central bottleneck. That mismatch is why old-school access programs fail. Not because IT and Security teams are doing a bad job, but because the system they inherited cannot keep up. This article pulls the most useful ideas from a recent conversation between Johannes Keienburg, CEO and Founder of Cakewalk, and Peter Kovacs, Head of Information Security at Nudge. It goes beyond the recap. It turns the discussion into a set of principles and decision points you can apply in your own environment. ‍ ## Key Takeaways - Access breaks when creation is distributed but governance stays centralized. - Ticket queues turn into rubber-stamping, permanent exceptions and standing privilege. - The fix is not hiring a larger IT team. It is better system design. - Role clarity and identity lifecycle automation do more than another policy document. - AI agents and other non-human identities expand risk faster than humans if left unmanaged. ‍ ## Why Access Management Breaks At 200, 400, Then 800 Employees In smaller companies, access feels manageable because the same handful of people know the stack and can answer most questions from memory. A request comes in. IT approves it. Everyone moves on. Once headcount grows, that model fails in predictable ways. New apps enter through teams, not IT. Managers approve access without context. People switch roles and keep old permissions. Departures happen fast and offboarding becomes inconsistent. Meanwhile IT and Security teams do not expand at the same pace. > "Access is created everywhere while governance stays manual and centralized." — Peter Kovacs, Nudge That is the root cause. Everything else is a symptom. ‍ ## The Three Failure Modes You Can Spot Early If you want a quick health check, look for these patterns. They show up in almost every company right before access becomes a constant source of risk and frustration. ### 1. The Ticket Queue Becomes The Policy When approvals are driven by tickets, the ticket backlog becomes the real rulebook. The longer the queue, the more pressure there is to clear requests without scrutiny. That is how rubber-stamping starts. People approve to keep work moving, not because the access is correct. ### 2. Exceptions Turn Into Defaults Temporary access is rarely temporary. Someone needs access for a project. They get it. The project ends. Nobody removes it. Standing privilege grows one exception at a time. ### 3. Evidence Lives In Too Many Places Audit questions are rarely complex. They are basic. - Who requested access. - Who approved it. - What changed. - Why it was granted. - How long it lasted. - When it was last reviewed. If you cannot answer those questions quickly, audits become a scavenger hunt across tickets, exports, spreadsheets and screenshots. ‍ ## A Better Model: Distributed Decisions, Central Policy Centralization becomes the problem when the people approving access are far from the business context where the need is created. That does not mean you decentralize policy. It means you separate decision-making from rule-setting. In practice, the model looks like this. - IT and Security set the rules, roles and guardrails. - Managers and app owners make decisions with context. - The system enforces policy and records evidence by default. You get speed where the work happens and control where it should live. This is also how you reduce bypass behavior. If the correct path is faster than the side path, people follow it. ‍ ## Lifecycle Plus RBAC: Triggers And Templates Most access programs fail because they treat every change like a new request. Joiners, movers and leavers are predictable identity events. They happen every week. If your access model is built around tickets instead of these triggers, you get the same problems on repeat: manual queues, inconsistent offboarding and permissions that accumulate over time. Peter’s approach at Nudge starts with a simple rule. HR is the most reliable signal that access should change. When HR drives identity change, access changes can be consistent, time-saving and auditable. That still leaves a second problem. What does the right access look like. This is where [role-based access control](/glossary/rbac) earns its place. The lifecycle tells you when access should change. RBAC tells you what should change. Without a clear permission map, automation can speed up overprovisioning. RBAC reduces ambiguity because roles create a shared language between IT, Security and the business. You can point to a role and answer the questions that matter to audits and operations. - Which roles exist - Who is in each role - What each role grants - Who owns the role - How often it is reviewed Put together, lifecycle triggers and role templates do the heavy lifting. New hires get the right baseline access on day one. Role changes update permissions instead of stacking them. Departures remove access without relying on someone remembering a checklist. This is not glamorous work, but it is the foundation that holds up when the company is hiring fast and auditors are asking hard questions. ‍ ## Least Privilege Only Works When It Applies To Leadership A standout moment from the conversation was a real story. The CEO at Nudge requested privileged access. The request was blocked and routed through Security. The CEO followed the process. Access was approved for a fixed time window, logged and then revoked. That is the point most companies miss. [Least privilege](/glossary/least-privilege) is not a policy. It is a behavior that becomes credible only when senior leaders follow the same rules. If leaders bypass controls, everyone learns the real standard. If leaders follow controls, the process becomes easier to defend and easier for employees to accept. ‍ ## Audit Readiness Should Be A Byproduct Of Daily Work Many teams treat audit readiness as a separate project. It becomes a quarterly push, a scramble for evidence and a set of late nights. Peter’s view was closer to how mature programs operate. Audit readiness should come out of normal operations. That only happens when evidence is captured by design. If you want audit work to shrink, focus on one thing. Make sure every access change produces a usable record without extra work. A good record includes: - Requestor - Approver - Reason - What changed - Duration - Review history If you have that, audits become verification, not reconstruction. ‍ ## Why AI Agent Access Is More Dangerous Than Human Access When asked what keeps him up at night going into 2026, Peter answered quickly. Non-human access. AI agents scale in ways humans cannot. With a few clicks, an agent can be connected to internal systems and external vendors. Many agents hold standing permissions. Some are controlled by multiple humans, which multiplies effective access. Agents also shift trust boundaries. You may trust your employee. But now you also need to trust the vendor, their staff, their subcontractors and their security posture. And the agent does not care about intent. It does what it is instructed to do. If misconfigured, it can do damage at machine speed. This is why agent access needs the same discipline as privileged access. ‍ ## A Practical Way To Govern Non-Human Identities You do not need a perfect solution to start governing agents. You need a consistent way to decide what is allowed. A useful starting point is to treat every agent like a privileged identity and ask the same questions you would ask for a human with elevated access. - What [NHIs](/glossary/non-human-identity) are out there (i.e., used by my teams)? - What systems do they touch. - What permissions do they get? - Who owns it. If you cannot answer those questions, the agent is not ready for production access. Peter also shared an internal approach that many teams can copy. Create a clear approval path for AI initiatives so engineers do not ship agent access through side channels. Give teams a place to propose use cases, get approval and document ownership. That keeps innovation moving while keeping access visible. ‍ ## What To Do If You Are Starting From Scratch Peter shared a simple sequence for a new environment. 1. Run a gap analysis against a clear standard you trust. 2. Tie role-based access to joiner, mover and leaver events. 3. Get visible buy-in from senior leadership. That last point is not a soft factor. It is operational. If leaders do not support the process when it is inconvenient, the process will not survive. ‍ ## Measuring Security Outcomes Without Turning It Into Theater A useful line from the conversation was about moving away from opinion-driven security. Security programs gain credibility when they can show measurable outcomes. You do not need a long list of KPIs. You need a small set that tells you whether the system is working. Here are a few metrics that tend to reveal the truth quickly. - Time to have a new joiner up and running with all access - Time to remove access after departure - Percentage of access that is time-based - Percentage of users with privileged access - Completion rate of [access reviews](/glossary/access-review) - Number of exceptions older than 30 days If those numbers improve, your security posture improves. If they do not, you know where to look. ‍ ## Final Thoughts Access management is no longer a secondary control. It determines whether your company can move quickly without accumulating silent risk. The strongest programs treat access as a system. They connect access to the identity lifecycle. They reduce ambiguity with roles. They make evidence a built-in output. They govern AI agents before agent access becomes invisible sprawl. If you are feeling the pressure, you are not behind. You are seeing the same structural shift that every growing company hits. ‍ ## See How Modern Teams Run Access Without Growing Headcount If you want to pressure-test your own access model, there are two easy next steps. [Chat with us in Slack](/slack-connect)‍ Connect with the Cakewalk CEO and product team. Bring your current setup, your edge cases and your audit constraints. Get direct answers in the place your team already works. [Book a Demo](/access-management-lp) [‍](/access-management-lp)Prefer a walkthrough? See how Cakewalk brings all identities, access, apps and AI agents into one system of record, automates access workflows and keeps you audit-ready by default. Make [Identity Governance](/glossary/iga-identity-governance) a piece of cake. ‍ ‍ --- # AI in Cybersecurity, Identity Governance & Access Management in 2026 _Well, SKYNET isn't quite here yet, but it feels awfully close, doesn't it? We've yet to see a robotic revolution, but it seems like with each passing week a new AI tool is storming the market and simplifying mundane tasks. Companies naturally jump at the chance to streamline tedium and reduce c_ By Johannes Keienburg, CEO & Founder Published: 2025-06-20 Source: https://www.cakewalk.security/blog/ai-cybersecurity-access-management-considerations --- Well, SKYNET isn't _quite _here yet, but it feels awfully close, doesn't it? We've yet to see a robotic revolution, but it seems like with each passing week a new AI tool is storming the market and simplifying mundane tasks. Companies naturally jump at the chance to streamline tedium and reduce costs, but this begs a few nagging questions: _How much, if at all, are companies taking security and compliance risks into account? _ _What even are those risks?_ AI has already proliferated across nearly every industry and team, making it a massive struggle for IT and security experts to control. On top of that, bad actors are using AI to enhance their attacks (e.g., AI-generated phishing scams that look authentic.) So let's take a deeper dive into AI's role(s) in cybersecurity and [identity governance](/glossary/iga-identity-governance). ## ‍The Bad ### A Double-Edged Sword: AI is for Hackers Too! A crowbar can help you pry open a crate, or it can help you do a smash-and-grab. It's all in how you use it. According to a report published by [Darktrace](https://www.darktrace.com/the-state-of-ai-cybersecurity-2025?s_kwcid=AL!14369!3!736844252639!b!!g!!cyber%20ai&gad_source=1#white-paper), "around 78% of CISOs surveyed believe that AI is having an impact on cyber threats today and are moving quickly to protect themselves. . . but around 45% of them feel they are not ready." And many governments are already legislating away to address privacy concerns with [NIS2](/glossary/nis2), and now even the [EU AI Act](/glossary/eu-ai-act) will govern AI specifically. AI is just a tool that can be wielded for good or for bad. Yes it can shut down anomalous behavior on a dime, but it can also be used to generate official-looking phishing emails, assist in social engineering efforts through deepfakes/impersonations, and even find and exploit unaddressed vulnerabilities at a massive scale. It's a never-ending game of cat-and-mouse, but we (the cat) need to stay ahead (of the mouse). Recently, we interviewed Rawad El Khoury, Engineering Director for Security at Aircall, and he explained this dichotomy thusly: "Attackers are leveraging AI more and more. As part of your internal framework, you need to validate and be sure that it's not impacting your performance or results, while from an attacker perspective it's trial and error. He tries it, if it doesn't work, he doesn't care. We as security professionals and security leaders need to put more effort into this side in order to get ahead of the attackers, not stay behind them." ‍ ### No Visibility: Shadow AI is the New Shadow IT [Shadow IT](/glossary/shadow-it) has long been a problem for CISOs in how it presents security risks and compliance issues. Unapproved systems have the capacity to store data insecurely and may violate data protection laws. However, this pales in comparison to [Shadow AI](/glossary/shadow-ai). Because AI's utilization has skyrocketed so quickly, companies introduce (and build) new AI tools at rapid speed. These tools host sensitive data and often have access to other company systems (non-human identities - [NHIs](/glossary/non-human-identity)!). Many of these are super useful on a day-to-day basis, **_but _**IT teams can't monitor what they don't know about, as with shadow IT. On top of that, NHIs may behave in unpredictable ways, as they are guided by their own internal logic. This underscores how oversight and control are more crucial than ever to avoid cans of worms like ethics and automated decision-making. ‍ ## The Good ### Authentication and Enhancing Zero-Trust Systems Through behavioral analytics, AI can log and categorize human behaviors and convert them into biometric and behavioural data, which is then used to create a profile for each user. Data analyzed includes everything from typing patterns and mouse movements to how each person interacts with touchscreen mobile devices (preferred orientation, typing vs. swiping, etc.) and usage times so that if there are deviations from the norm, they will be immediately flagged. Once suspicious activity is flagged, it can automatically trigger [multi-factor authentication](/glossary/mfa) and notify the proper authority. ### AI Detects. AI Prevents. If there's one thing that AI is good for, it's analyzing large volumes of data in real-time to detect patterns and understand behaviors, which helps enhance security beyond authentication. As you may expect, this is ideal for cyber security. Manual anomaly detection can be a slow and painstaking process, but an AI program can detect and flag any abnormal patterns such as unapproved data transfers. AI can even draw correlations between low-risk events that may eventually become a more serious attack down the line. ### Enhancing Access Controls AI has the capability to enable pattern and/or context-based access privileges and suggest access rights accordingly. This streamlines [role-based access control](/glossary/rbac) (RBAC) and [attribute-based access control](/glossary/abac) (ABAC) creating a more granular approach to access management. ### ‍Automating Policy Creation & Review AI tools can draft, update, and help standardize your security policies based on your industry's best practices, new legislation, and even your individual needs. For instance, you could have it: - Generate policy templates and suggestions - Improve and tailor existing policies through comparative analysis - Find gaps between regulatory standards and your current policies - Highlight vague or inconsistent language within policies that may not align with intent - Automate reviews of policies likely to be affected by incoming legislation ### Automated Identity Governance is a Piece of Cake Cakewalk is the new standard in identity governance, designed to get you up-to-speed on state-of-the-art access management tools and cybersecurity requirements. We help you achieve full visibility over all employee apps, control and restrict access, and auto-remove 100% of seats during offboarding. How has AI affected your industry? How can we as an InfoSec community stay ahead of cybercriminality? [Join the conversation on LinkedIn](https://www.linkedin.com/posts/cakewalk-security_governing-ai-is-the-new-daily-struggle-of-activity-7333035602302373890-D5pj?utm_source=share&utm_medium=member_desktop&rcm=ACoAABSslTcBpoMH3D9pp-u7D0VHHm1AcpCghIQ)and tell us your thoughts! --- # Everything Financial Companies Need to Know about DORA _While we've recently covered NIS2, the AI Act, and other sweeping regulations that address tech innovations, the EU's Digital Operational Resilience Act seems to have flown under the radar for many. Possibly in part due to its esotericism or being kept in the dark about how it will affect non-E_ By Johannes Keienburg, CEO & Founder Published: 2025-06-19 Source: https://www.cakewalk.security/blog/what-is-dora --- While we've recently covered [NIS2](/glossary/nis2), the AI Act, and other sweeping regulations that address tech innovations, the EU's Digital Operational Resilience Act seems to have flown under the radar for many. Possibly in part due to its esotericism or being kept in the dark about how it will affect non-EU entities, many companies we interact with haven't taken action to become compliant. So what is DORA? How will it affect you? What are its implications for the future? Here we'll answer all of these questions and more. ### What is DORA? DORA is a piece of EU legislation that aims to improve the digital resilience of financial companies and institutions. Cyberattacks and system failures greatly hinder a financial institution's ability to operate and protect sensitive data. DORA aims to mitigate these issues and prepare organizations with the procedures they need to rebound quickly if a cybersecurity incident occurs. The new law was introduced to the EU in January 2025, affecting not just financial entities, but also: third-party service providers (yes, even ones not in the EU!) So, it’s actually very likely that DORA affects you too—at least as a 2nd-order consequence. ‍ ### What's in DORA That You Should Care About? **First Off, it Requires Action From Your End.** What actions are those, exactly? Glad you asked. Under DORA, you'll need faster incident reporting and response plans, you must audit all of your vendors and partners (even those not in the EU) to ensure they are compliant, and it raises the bar for [IGA](/glossary/iga-identity-governance) policies. The EU loves to create legislation that doesn't just affect its member states, but their entire networks as well—and DORA is no exception. Third-party vendors and partners will need to be more heavily scrutinized to ensure that they are also remaining compliant. This includes: - Evaluating and understanding which vendors are most important to your operations. - Reviewing their cybersecurity infrastructure and business resilience plans. - Ensuring each vendor meets the same standards as you do and that the upcoming law requires. DORA has very stringent requirements on quick and accurate incident reporting so that you know the who, what, where, when, why, and how of each and every cyber incident. In the event of a post-incident audit, you should be able to answer detailed questions that regulators may ask, such as "what does your [incident response](/glossary/incident-response) plan look like? Were access privileges misused? Can you verify the event timeline? Who accessed the data and how?" And an automated identity governance plan ensures these conversations are held quickly and without headache. Reportable incidents include any ICT event that impacts confidentiality, integrity, or availability of data, or if it has material impact on operations or critical services and functions. Companies and institutions are also required to classify the severity of each incident using predefined criteria in order to execute the proper response plan. Lastly, DORA requires strong internal ICT security practices. Specifically, when it comes to identity governance, every identity should only access necessary systems and nothing more. It utilizes [least-privilege](/glossary/least-privilege) principles, meaning all financial organizations must limit, monitor, and review privileged access accounts because they carry the most significant threats if compromised. Therefore, automated identity governance workflows have never been more essential. ### Why Should European Companies Care? DORA may change how you do business, or indeed who you do business with. But let's wade a little deeper to highlight exactly why you should care. #### There are Hefty Penalties for Non-Compliance (Plus Board/Executive Accountability) If you're involved in the financial sector in any capacity, compliance is mandatory. Noncompliance comes with a slew of penalties based on the severity of the violation, including fines and even operational restrictions, not to mention intangible consequences like reputational damage and lost trust — which actually might be the most costly consequence of all. Monetary penalties include: - **For institutions: **Fines of up to 2% of total annual worldwide turnover or 1% of average daily worldwide turnover. - **For individuals:** Up to €1,000,000 in fines. - **For third-party ICT providers: **Up to €5,000,000 for organizations or €500,000 for individuals. Administrative penalties, which are reserved for serious or repeat offenders, include: - Suspended or revocation of operational licenses. - Mandatory implementation of enhanced, compliant security measures at the business' expense. Plus, under DORA, IT teams are not alone — boardrooms and executives can be held accountable and thus must also be aligned with ICT risk management strategies. Personal, board-level accountability measures include: - Criminal charges for gross negligence — this is a big one! Just wondering: Do your senior executives and board members know…? - Imprisonment (!) in the rare instance of willful and intentional non-compliance that leads to systemic instability. #### It Provides Operational Stability Having safety nets and processes, such as a platform or team dedicated to managing cybersecurity, will help you recover quickly from a cyber incident, which is now the law in the EU. It helps you maintain operations in the face of outages, infrastructure failures, data corruption, etc. Reducing downtime is especially critical for financial institutions if they want to stay in the good graces of their customers and not lose out to competition who actually make the effort to stay compliant. #### Don't You Want to Maintain a Competitive Advantage? You're always looking to stay one step ahead, right (nod yes even if it's not true)? Well, now is your time to shine. You have the opportunity to use compliance as a PR boon to market your newfound differentiator. Get ahead of the curve by showing your ability to adapt to new legislation (and remain stronger and more secure as a result.) You may deal with Euros, Pounds, and Dollars each day, but don't forget that trust is also a currency; and it's one that can be depleted very quickly. Vendors and partners may be quick to switch to more trustworthy options if you can't or won't comply. #### It Forces Transparency in Third-party Risks Chances are you rely on some form of external services. DORA has the potential to completely complicate your vendor relationships. If your vendors aren’t compliant, you can’t legally use them anymore. From impacting suppliers and rewording contractual agreements, there's a chance you may have to form new vendor relationships if you want to avoid costly fines and potential loss of revenue due to inability to proceed with business as usual. At the very least, you'll need to audit each of your vendors to ensure compliance and it may lead to restructuring. ### Future-proofing Against Broader Regulatory Pressures is Smart DORA isn't the first piece of cybersecurity legislation, and it surely won't be the last. It's just one link in a long chain of ever-evolving compliance requirements. But the fact of the matter is that other countries and other industries are also adopting similar security legislation, so even if you aren't directly affected by DORA at the moment, it's still smart to implement measures and future-proof yourself against other, more sweeping regulations. You're not even in the EU, so you won't be affected, right? Wrong! Unfortunately for you, if you work with a financial entity within the EU, you are compelled to comply. Here's why: If you provide any form of IT, cloud, or other digital services to an EU financial entity, you can bet that they will be auditing your practices to ensure DORA compliance. They need full omniscience into every cyber risk and thus must know any risk you pose. If you don't want to get dropped by your EU clients, you'll have to comply. As we covered previously, DORA and other legislation are emblematic of a global trend toward reinforcing critical sectors that are reliant on digital tools. Complying with DORA is just the first step toward maintaining an efficient business and sets you up for an easy transition once your country inevitably passes its own similar legislation. ### Here are some steps you can start taking to avoid hefty fines and penalties. **1. Establish Governance & Accountability** - Assign executive-level responsibility for ICT risk and DORA compliance (board, CISO, compliance officer). - Update internal policies and governance frameworks to include DORA requirements. - Ensure cross-departmental coordination (IT, risk, legal, compliance, procurement). **2. Strengthen ICT Risk Management** - Conduct a comprehensive ICT risk assessment (systems, data, processes). - Define and apply risk-based controls (e.g., network segmentation, backup policies). - Implement continuous monitoring of ICT risks and vulnerabilities. **3. Implement Robust Access & Identity Controls** - Apply [role-based access controls](/glossary/rbac) (RBAC) and least-privilege principles. - Enforce privileged access management (PAM) and track elevated permissions. - Automate [access reviews](/glossary/access-review) and certification to ensure entitlements remain appropriate. **4. Build Incident Reporting Procedures** - Define what constitutes a major ICT incident under DORA. - Set up incident response playbooks covering classification, escalation, and notification. - Prepare to meet 4-hour, 3-day, and 1-month reporting deadlines. - Implement systems to log, track, and analyze security events and access anomalies. **5. Harden Third-Party Risk Management** - Create or update a third-party inventory (especially ICT providers). - Review contracts to include DORA-aligned clauses (e.g., audit rights, incident disclosure, cooperation obligations). - Evaluate third-party cybersecurity posture and require regular performance reviews. Side note: This is how the entire DORA thing trickles down! - Develop exit strategies for critical vendors to reduce concentration risks. **6. Prepare for Resilience Testing** - Conduct threat-led penetration testing or advanced simulation exercises on critical functions. - Test backup, recovery, and continuity plans. - Document lessons learned and integrate them into risk mitigation strategies. **7. Enhance Documentation & Audit Readiness** - Maintain an ICT incident register with clear records of past events. - Ensure detailed documentation of policies, processes, controls, and risk assessments. - Prepare internal audit teams for DORA-specific supervisory reviews. **8. Invest in Continuous Compliance & Improvement** - Deploy tools for automated compliance monitoring and reporting. - Train staff on DORA requirements and operational resilience principles. - Establish a feedback loop to regularly improve controls, processes, and governance. **Make Compliance a Cakewalk** Compliance isn't a one-time project; it's an ongoing process. Cakewalk is the new standard in identity governance, designed to get you up-to-speed on DORA and other cybersecurity requirements. We consolidate all access, apps and AI agents, fully automate workflows, and get guidance based on insights—enabling your teams while reducing your attack surface. To learn more, get in touch today. --- # The Future of Identity Governance is Employee-Centric. Here's Why. _Poor access management practices are one of the most significant security risks facing any IT team. In fact, a recent Verizon report found that 43% of breaches are performed via applications as an entry point—underscoring how traditional access management paradigms are no longer cutting it._ By Johannes Keienburg, CEO & Founder Published: 2025-06-18 Source: https://www.cakewalk.security/blog/employee-centric-iga --- Poor access management practices are one of the most significant security risks facing any IT team. In fact, a recent [Verizon report](https://www.verizon.com/business/resources/reports/dbir/) found that 43% of breaches are performed via applications as an entry point—underscoring how traditional access management paradigms are no longer cutting it. Today, teams are hybrid, spanning multiple networks and devices. Most companies rely on an exploding SaaS and now also AI stack—each tool expanding the attack surface. AI agents are starting to request access alongside human users—non-human identities, but they are still introduced by: humans! And all of this is happening as regulations like [NIS2](/glossary/nis2), the [EU AI act](/glossary/eu-ai-act) and DORA demand more transparency, stricter controls, and faster [incident response](/glossary/incident-response). Shifting toward an employee-centric access management model is not only a scalable and secure solution for today's workforce, but it is mission critical if you expect to reduce access-related risk, shrink your attack surface or cut down the operational overhead that comes with manual access management—to finally tackle the problem where it arises. Every IT & Security team we interact with is experiencing the same challenge: Teams often don't comply with their governance and don't stick to the process. Employees don't care about access tickets (and why should they), they just create access. Employees are doing this not because they are malicious, but because they are busy. Therefore, employees need an [identity governance](/glossary/iga-identity-governance) process that makes it easy, helps them understand why it matters, and implements solutions that bring them value. So let's dive into employee-centric [access controls](/glossary/access-control) and see why this strategy has become the gold standard for so many teams—and how AI can help shape an employee-friendly approach. ## Employee-Centricity and RBAC are NOT Mutually Exclusive It’s easy to think of the “black and white” [Role Based Access Controls](/glossary/rbac) (RBAC) and Employee-Centric Access Controls (ECAC) as being mutually exclusive. Think of RBAC as a building’s default floor plan (who can go where) and employee-centric controls as personalized keycards that can be updated based on evolving needs without rebuilding the whole structure. Here’s how to properly combine the two for the best possible outcomes (as we know it today): **1. Use RBAC as a Foundation and Keep IT in Ultimately Charge:** - Create well-defined roles that match your organizational structure (e.g., Sales Rep, Finance Lead). - Assign permissions conservatively (principle of [least privilege](/glossary/least-privilege)). - Extra for your employees: It’s good for them too if there is a clear cut and everyone knows what team gets what access! ‍**2. Allow Scoped Exceptions or Extensions to Serve Employee Needs:** - Layer attribute-based or task-based access on top of roles. - Example: An SEO Analyst (within “Marketing” role) may get temporary or project-based access to a PPC dashboard if they're covering during PTO. **3. Enable Self-Service:** - Based on the birthright role-based access (again: which is a great start for new employees, see above), enable every employee to request additional access in an easy-to-follow and intuitive (!!!) manner. **4. Monitor and Adapt:** - Use workflows that notify IT/security for review, logging everything for audit. Things need to be kept in order and tracked for audits such as [ISO 27001](/glossary/iso-27001) compliance—so central teams don’t have to chase people in order to find out who has access to what. - Use tools like [dynamic access reviews](/user-access-review-software) to remove stale or excessive permissions. In other words: Employee-centric access controls are an adaptive approach to identity governance in which access rights are granted, monitored, and revoked based on a holistic view of the employee—their current role, responsibilities, context, behavior patterns, and risk level at any given moment. And in a manner that makes it easy for people to contribute to identity governance as a shared responsibility. AI will massively help simplify these processes—and that’s almost a paradox: AI is making the problem worse (more access!), but it’s also helping to bring access under control. Speaking of distributed responsibility: One of the key underlying aspects of employee-centric access controls is the concept of decentralization. Recently, we spoke with Siebert Timmermans, an Information Security Officer & Advisor who works with startups and scaleups to help them implement better security practices. He told us: "One of the worst things you can do from a risk and time perspective is having one or two super admins in every single tool; they have to manage all configuration and access controls for everyone in the company. If you do this, you're setting yourself up for failure. . .a better way is to decentralize it; having the people who actually work with these tools day in and day out treat them in a responsible manner. They are responsible for configuring and maintaining the tool, for giving access, changing access, managing privileges, etc. Clarify what the responsibilities and expectations are and hold them accountable." **-Siebert Timmermans, Information Security Officer & Advisor** And he's completely right. So many other aspects of a business' operations are decentralized, so why should the full onus of identity governance fall solely on your IT team? The crux is, every owner needs to contribute to Identity Governance and Administration (IGA) and the process. Rather than one IT team owning all tools, issues, troubleshooting, and adoption processes, each power user or app "champion" in a department should be able to handle day-to-day issues while the IT department manages and oversees overall security infrastructure to mitigate risk and create a team-based model. We are saying it again: IGA is a shared responsibility. We see this model in a number of other business functions as well: - **Content production/social media**: Rather than one team creating and approving all content across locations and departments, local teams should instead create their own content that's tailored to their specific audience, while adhering to pre-approved templates and branding guidelines. The marketing team comes in to ensure everything is compliant with overall principles and on-brand (just like: RBAC). This makes the content more authentic and aligns with local trends while ensuring company wide processes are adhered to. - **Budget management: **If one finance department acts as the decisionmaker for each team, needs often get overlooked or improperly prioritized. But when department leads are empowered to manage their own budgets (**with general oversight from the finance team)**, it allows for quicker and more effective decisionmaking based on deeper understanding of their teams' needs. - **Customer Relationship Management: **Decentralized CRM teams facilitate stronger client relationships. It empowers each rep to manage their clients based on actual interactions, rather than theoretical guidance from the top. Again, a centralized team should be empowered to oversee and ensure processes are adhered to. ## Implementation: What to Consider Before Rolling It Out - Management **must (!) **make identity governance and administration a top priority organization-wide and clearly communicate the imperative nature of everyone to stick to the process—ideally this starts with CEO messaging WHY this matters - Engage IT, InfoSec, HR, Compliance, and business unit leaders early and regularly - Clarify roles in policy creation, access approvals, and recertification - Identify and assign data owners/system owners in a distributed manner #### 2. Assess Current State of Identity & Access - Process: Audit existing access control methods (RBAC, manual provisioning, AD groups, etc.) - Map out identity lifecycle stages and current automation gaps - Identify where privilege creep or orphaned accounts currently exist - Inventory specifically critical applications, systems, and data that need governance - The ultimate goal is to implement a process that is clear to users, gives freedom to them (while being clear about their obligations to stick to the process), and that orchestrates IGA in a distributed manner in which IT & Security oversee rather than doing everything themselves Map triggers for role-based onboarding, role change, leave of absence, and offboarding (JMLs!) - Automate provisioning/deprovisioning based on role, location, contract status - Set rules and workflows for temporary or just-in-time access - Chose a platform that can automate your key processes, allows your to consolidate all access data—and, guess what: That is not only great for IT & Security teams, but also easy to use for your entire organisation - Otherwise you’ll find yourself back to square one—people will ignore your system - Ensure real-time monitoring of user activity and contextual anomalies - Prepare audit-ready reports for [GDPR](/glossary/gdpr) and DORA inspections - Run a controlled pilot with a test group - Educate managers on your new process - Create end-user guides for your new self-service process - Schedule periodic reviews of your entire process Not sure where to start? Cakewalk has you covered… ### Cakewalk Helps Future-Proof Your Identity Strategy Traditional IGA models can't keep up with global teams, hybrid environments, and the increase in contractual labor. Ever-tightening regulations require companies not just to be reactive in a very short timeframe, but also to implement more proactive measures. As your company continues to evolve and adopt new platforms, your IGA strategies have to keep pace without holding back your potential to scale quickly. Cakewalk provides the ability to consolidate all access, apps and AI agents, fully automate workflows, and get guidance based on insights. We enable your teams while reducing your attack surface all while ensuring you're complying with incoming cybersecurity regulations. Book a demo to find out how Cakewalk can improve your IGA process. --- # 3 Ways NIS2 Will Affect UK Companies (Yes, We're Serious) _Despite Brexit's determination to break from the EU, many UK companies still do business with and within the EU in some capacity, meaning that EU legislation may not directly impact UK businesses, but it can still heavily influence them — as is the case with NIS2._ By Johannes Keienburg, CEO & Founder Published: 2025-04-22 Source: https://www.cakewalk.security/blog/blog-nis2-uk --- ## The EU's NIS2 Legislation Will Probably Affect Your UK Business. Here's How.‍ Despite Brexit's determination to break from the EU, [many UK companies](https://commonslibrary.parliament.uk/research-briefings/cbp-7851/) still do business with and within the EU in some capacity, meaning that EU legislation may not _directly_ impact UK businesses, but it can still heavily influence them — as is the case with [NIS2](/glossary/nis2). While the UK does have its own cybersecurity legislation such as the [Cybersecurity and Resilience Bill](https://www.gov.uk/government/collections/cyber-security-and-resilience-bill), the recent EU-driven initiative compels [all vendors and partners to comply](https://www.computerweekly.com/feature/How-UK-firms-can-get-ready-for-the-implementation-of-NIS2) with NIS2. So by proxy, any UK partners involved in an EU company's supply chain might be up a creek without a paddle if they don't comply. It would behoove UK companies to be up-to-date on the legislation and even adhere to it if they don't want to lose business or close down their international locations. We get it — it's hard to care about other countries' legislation if it isn't directly affecting you. But in our globalized world, _everything _is interconnected, even EU regulation... Such large directives have rippling effects that you can and should anticipate. But what is NIS2, what are its implications for non-EU partners, and how can you stay ahead of the curve without dedicating too many resources to it? We'll answer all of these questions and more, so read on. ## So, what even is NIS2? ‍ NIS2, the Network and Information Security Directive, is new cybersecurity legislation that will apply to many companies within EU-countries. It is an updated form of the original NIS1 legislation that now prioritizes: - Higher cybersecurity standards - Expanded scope - Stricter incident reporting - Security among vendors and partners (read: The one that you should be most concerned with) - Increased regulatory scrutiny - Heavier penalties and fines for non-compliance Whereas the previous NIS legislation applied only to essential services and some digital services, NIS2 categorizes applicable businesses into two categories — [essential entities and important entities](https://nis2directive.eu/who-are-affected-by-nis2/) — each with their own scope and respective compliance requirements/penalties. So, why should you care? ## UK Companies with EU Operations or Clients Must Comply ‍ _"But we're not located in the EU. We just have partners there, so it won't apply to us, right?"_ Wrong. Why should another country's laws dictate your business? Because life isn't fair, that's why. By EU law, any and [all vendors or partners](https://www.bureauveritas.co.uk/needs/network-and-information-security-directive-nis2) that EU companies work with must comply with NIS2, regardless of where they're located. So if you expect to keep uninterrupted business operations, you'll have to appease your clients lest they drop you entirely. The new compliance scope includes UK businesses that: 1. Have subsidiaries, offices, or a data center within the EU 2. Supply critical services to EU-based companies 3. Are involved in supply chains for EU companies So, yes, it goes without saying that if you have operations in the EU you also must comply (and hopefully you're already on top of it). _Not already on top of it? Skip down to the NIS2 compliance checklist now._ Non-EU entities operating within the EU must appoint a representative within the EU to ensure compliance at those locations. ## Higher Cybersecurity Standards Means… But what does "higher standards" actually mean? Glad you asked. ### …expanded scope of affected sectors - **Energy**: Electricity, oil, gas, and others. - **Transportation:** Logistics providers (including postal/courier services), as well as air, rail, water, and road transit companies. - **Banking: **Any financial service or credit institution. - **Healthcare: **Care providers, labs, and hospitals. - **Essential services:** Companies that handle potable water, waste treatment/disposal, data centers, domain service providers, government entities at both regional and national levels, and more. - **Food production: **Any company that processes or distributes food products. - **Manufacturing: **Any manufacturer that deals with chemicals, medical devices, or pharmaceuticals. - **Digital services: **This is extremely broad and far-reaching. It includes social networks, cloud services, online marketplaces, search engines, and any other service that is offered digitally. Essentially, you'd be hard-pressed to find an industry that it doesn't apply to. ### …stricter incident reporting requirements A cybersecurity incident MUST be reported if it: - Has the potential to disrupt essential services - Affects supply chains or business operations - Data breaches resulting in loss or compromising of internal data - Impacts public safety and trust When a cyber incident does occur, companies must now report them within 24 hours of its discovery, with follow-up reports after 72 hours (which detail the damage done) and a final report within one month (which provides a full analysis of long-term security improvements). If the threat spreads or becomes worse, more frequent reports must be filed to the appropriate authorities. Additionally, companies must inform their customers if their data is at risk. NIS2 also employs a [**zero-trust**](/glossary/zero-trust)** security model** under which more frequent user verification is required. This subsequently tightens [access control](/glossary/access-control) for internal tech stacks. ### …tighter supply chain and vendor scrutiny NIS2 places a heavy emphasis on supply chain and taking aim at third-party risks. Audits and due diligence of all partners' and vendors' cybersecurity measures must be completed to ensure they all comply with NIS2. Business continuity and crisis management plans are no longer a nice-to-have, but an absolute must-have. Failure to comply will result in fines and/or loss of business with EU partners. ### …increased regulatory scrutiny Under NIS2, legal fines can easily amount to **EUR 10 Million or more**. As for UK businesses, hefty fines and potential bans from operating within the EU are definitely on the table. Plus, if the EU’s stricter rules wind up influencing future UK cybersecurity legislation (which it already seems to be doing with the recent Cybersecurity and Resilience Bill), won't it be nice to be ahead of the curve? ## What Do You Do if You're Affected? Keep Calm and Carry On With This NIS2 Checklist #### 1. Appoint an EU Representative - If you operate in the EU but don’t have a physical presence, designate an **EU-based representative** to handle compliance. - Ensure the representative is authorized to interact with regulators. #### 2. Implement Stronger Cybersecurity Measures - Adopt a **risk management approach** with clear cybersecurity policies. - Regularly **audit and test** security measures (penetration testing, vulnerability assessments). - Protect **critical assets** using encryption, firewalls, and endpoint security. - Ensure **secure access control** ([multi-factor authentication](/glossary/mfa), role-based access). - Implement **incident detection and response systems**. #### 3. Meet Incident Reporting Requirements - Develop a clear [**incident response**](/glossary/incident-response)** plan**. - Be prepared to report cyber incidents within **24 hours**. - Submit a full report to EU authorities within **72 hours**. - Document security incidents for compliance audits. #### 4. Strengthen Supply Chain and Third-Party Security - Ensure vendors and partners handling EU data comply with **NIS2 security standards**. - Conduct **regular risk assessments** on third-party providers. - Require **cybersecurity clauses** in supplier contracts. #### 5. Compliance and Governance - Assign a **Chief Information Security Officer (CISO)** or compliance officer. - Train employees on **cyber risks and incident response**. - Keep records of **risk assessments, compliance efforts, and audits**. - Implement **business continuity and disaster recovery plans**. #### 6. Monitor Changes and Penalties - Stay updated on **EU cybersecurity regulations**. - Be aware that non-compliance could result in **fines up to €10 million or 2% of annual global turnover**. - Work with **legal and cybersecurity consultants** if needed. Lastly, you need a strategic partner on your side that can help you make meaningful changes to become NIS2-compliant. ## NIS2 Compliance Can be a Cakewalk Cakewalk is the new standard in access management, designed to get you up-to-speed on NIS2 and other cybersecurity requirements. We eliminate [shadow IT](/glossary/shadow-it), facilitate self-service access, automate on- and offboarding, help you run [access reviews](/glossary/access-review), and more. To learn more about how you can enhance access management in order to stay compliant with new legislation, [get in touch today](/). What have you done to prepare for NIS2? What are your thoughts? Join the conversation on LinkedIn or get in touch to share! --- # Deutschland: Wach auf und mach dich bereit für NIS2! _Der 17. Oktober 2024 war das offizielle Zieldatum für die Umsetzung der bahnbrechenden Gesetzgebung – bekannt als die Network and Information Security Directive (NIS2) – durch die EU-Mitgliedstaaten. Doch in einer Wendung deutscher "Effizienz" haben es z Germans nicht rechtzeitig geschafft – es_ By Johannes Keienburg, CEO & Founder Published: 2025-02-06 Source: https://www.cakewalk.security/blog/deutschland-wach-auf-und-mach-dich-bereit-fur-nis2 --- Der 17. Oktober 2024 war das offizielle Zieldatum für die Umsetzung der bahnbrechenden Gesetzgebung – bekannt als die Network and Information Security Directive ([NIS2](/glossary/nis2)) – durch die EU-Mitgliedstaaten. Doch in einer Wendung deutscher "Effizienz" haben es z Germans nicht rechtzeitig geschafft – es wird tatsächlich eine neue deutsche Regierung brauchen, um NIS2 umzusetzen... Da es also eine deutsche Verspätung gibt, bleibt die Frage: Warum haben Sie noch keine Schritte unternommen, um konform zu werden? Fakt ist: Die Cybersicherheitslandschaft verändert sich, und das wird Auswirkungen auf Unternehmen haben – ob sie gesetzlich verpflichtet sind oder nicht... Werfen wir einen Blick auf einige dieser Auswirkungen und darauf, wie Sie aufholen können, um ein NIS2-Vorzeigebeispiel zu werden.**Jeder hat eine Ausrede…** _"Das gilt nicht für uns." "Ist viel zu teuer." "Wir machen das später." "Cybersecurity, schmybersecurity"_ Schlechte Ausreden, die wir immer wieder hören… Aber Ausreden für die Nichteinhaltung sind... nun ja, unentschuldbar. Selbst wenn Sie glauben, dass Sie nicht verpflichtet sind, gilt: Unwissenheit ist keine Verteidigung. Proaktives Handeln ist die einzige Möglichkeit, unnötige Geldstrafen und Sanktionen zu vermeiden. ### "Was? Was ist NIS2..?" Oh je… Falls Sie davon noch nichts gehört haben: [NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) ist eine neue EU-Richtlinie, die rechtliche Rahmenbedingungen für die Cybersicherheitsmaßnahmen der EU-Mitgliedstaaten festlegt. Sie ist eine Aktualisierung von NIS1, das ähnlich funktionierte, aber NIS2 erweitert den Geltungsbereich erheblich (betrifft mehr Branchen und Unternehmenstypen), stellt striktere Regeln auf und führt neue Haftungsmaßnahmen ein (sprich: höhere Strafen). Während NIS1 Kernsektoren wie Energie, Gesundheitswesen, Finanzen und Wasserversorgung abdeckte, zieht NIS2 ein deutlich weiteres Netz – siehe unten für mehr Details. ### "NIS2-Compliance ist zu teuer!" Wissen Sie, was teurer ist? Die Konsequenzen der Nichteinhaltung. Es ist verständlich, dass kleinere Unternehmen oft nicht die Ressourcen haben, um ihre Cybersicherheitsinfrastruktur aufzurüsten, und dass Mitarbeiterschulungen zeitaufwändig und kostspielig sind. Allerdings betragen die durchschnittlichen Kosten eines Data Breaches für deutsche Unternehmen 5,13 Millionen Euro ([average cost of a data breach](https://www.csoonline.com/article/567697/what-is-the-cost-of-a-data-breach-3.html)) – und dazu kommen noch rechtliche Strafen von 10 Millionen Euro oder mehr. In den meisten Fällen sind Sicherheits-Upgrades der weniger schmerzhafte Weg. Zudem können Geschäftsführer unter NIS2 persönlich haftbar gemacht werden – eine der wesentlichen Änderungen von NIS1 zu NIS2. Dazu kommen indirekte Kosten wie Betriebsunterbrechungen, Reputationsschäden und finanzielle Verluste, die Sie jetzt vielleicht noch gar nicht auf dem Schirm haben. ### "Wir haben keine Zeit!" Verständlich. Der tägliche Betrieb ist schon genug Aufwand und Compliance-Maßnahmen stehen nicht unbedingt an erster Stelle. Aber diese Ausrede ist bestenfalls dünn und schlimmstenfalls einfach falsch. Drei Gründe: 1. Cybersicherheitsvorfälle können Ihren Betrieb lahmlegen und Sie in Panik versetzen – am Ende kostet es mehr Zeit und Geld als ein Compliance-Programm. 2. Schleichende Veränderungen sind einfacher als ein plötzlicher Komplettumbruch. 3. Ein externer Experte kann die zeitliche Belastung für Ihr Team deutlich reduzieren. ### ‍"Uns interessiert Cybersicherheit nicht." **‍**Nun ja, Cybersicherheit interessiert sich aber für Sie. Sicherheitslücken kleinzureden ist brandgefährlich. Ja, man liest vor allem über große Hacks in den Medien, aber die meisten Angriffe richten sich gegen kleinere Organisationen. Warum? Weil diese ihre Sicherheit oft vernachlässigen. Ihre Sicherheitsmaßnahmen können darüber entscheiden, ob jemand Ihr Produkt kauft oder nicht. NIS2 legt großen Wert auf Lieferkettensicherheit, da Schwachstellen bei Dritten eine der größten Risiken darstellen. ### ‍"Betrifft uns nicht!” Auch wenn Sie nicht unter NIS1 fallen - NIS2 hat einen größeren Umfang, der mehr Sektoren abdeckt als zuvor, also ist Vorsicht geboten. Aber da dies die häufigste Ausrede ist, die wir hören, schauen wir uns das ein wenig genauer an. ### ‍Ja, es betrifft wahrscheinlich auch Sie - zumindest wird es das irgendwann tun… ‍ Die neue Liste der von NIS2 betroffenen Industrien umfasst: - **Energie: **Elektrizität, Öl, Gas, etc. - **Transport: **Logistikdienstleister (einschließlich Post-/Kurierdienste) sowie Luft-, Bahn-, Wasser- und Straßenverkehrsunternehmen - **Banken: **Alle Finanzdienstleistungs- oder Kreditinstitute - **Gesundheitswesen:** Pflegeeinrichtungen, Labore und Krankenhäuser - **Essenzielle Dienstleistungen:** Unternehmen, die Trinkwasser, Abwasserbehandlung/-entsorgung, Rechenzentren, Domain-Service-Anbieter, staatliche Stellen auf regionaler und nationaler Ebene und mehr handhaben. - **Lebensmittelproduktion: **Jedes Unternehmen, das Lebensmittelprodukte verarbeitet oder vertreibt. - **Fertigung: **Jeder Hersteller, der mit Chemikalien, medizinischen Geräten oder Pharmazeutika zu tun hat. - **Digitale Dienstleistungen:** Dies ist äußerst breit und weitreichend. Es umfasst soziale Netzwerke, Cloud-Dienste, Online-Marktplätze, Suchmaschinen und jede andere Dienstleistung, die digital angeboten wird. NIS2 kategorisiert Unternehmen in “Essenziell” und “Wichtig”, je nach Branche und Größe. Sie können mehr über die Bezeichnungen [hier](https://nis2directive.eu/who-are-affected-by-nis2/) lesen. Dieser neue Umfang wird voraussichtlich 30.000 Unternehmen nur in Deutschland und [100,000](https://www.essendi.de/en/nis-2-what-businesses-need-to-know-right-now/) EU-weit betreffen. Unternehmen [mit 50 oder mehr Mitarbeitern und einem Jahresumsatz von mehr als 10 Millionen EUR](https://nis2directive.eu/who-are-affected-by-nis2/) werden schließlich den Compliance-Vorgaben unterliegen. Wenn Sie also planen, Ihr Geschäft in der Zukunft auszubauen, sollten Sie frühzeitig mit der Planung für NIS2 beginnen. Zu guter Letzt: Ihre Kunden könnten von NIS2 betroffen sein und möchten, dass ihre Lieferanten ebenfalls compliant sind. Das sehen wir tatsächlich oft… Wir haben es schon gesagt und sagen es daher noch einmal: Nicht-Compliance kann Sie potenzielles Geschäft kosten, wenn andere Unternehmen dies von ihren Anbietern oder der Lieferkette verlangen. Deshalb sagen wir: Ja, es betrifft wahrscheinlich auch Sie, oder zumindest wird es das irgendwann tun.**‍** ## NIS1 vs. NIS2: Was hat sich geändert? **‍**NIS2 verschärft die Anforderungen, erweitert den Geltungsbereich und erhöht die Strafen. Einige der neuen Anforderungen: - **Strengere Meldepflichten**: Cybervorfälle müssen innerhalb von 24 Stunden gemeldet werden. - **Geschäftskontinuitäts- und Krisenmanagementpläne**: Jetzt verpflichtend. - **Lieferketten-Sicherheit**: Unternehmen müssen ihre Drittanbieter auf Sicherheitsrisiken prüfen. - [**Zero-Trust**](/glossary/zero-trust)**-Prinzipien**: Striktere Authentifizierungsverfahren. Und keine Sorge, zusätzlich zu den neuen, hohen Geldstrafen verlangt NIS2 auch eine persönliche Haftung für Führungskräfte und Unternehmensvorstände - eine bedeutende Veränderung, die das Management von Firmen sicherlich dazu bringen sollte, sich mit den Compliance-Updates auseinanderzusetzen!**‍** ## NIS2-Maßnahmen, die Sie bereits gestern hätten ergreifen sollen Aber es ist noch nicht zu spät. Dieser gesamte Prozess könnte bis zu einem Jahr dauern, also je früher Sie anfangen, desto besser! ### ‍1. Governance und Risikomanagement - Bestimmen Sie eine verantwortliche Person (oder ein Team) für die NIS2-Compliance. - Führen Sie regelmäßige Risikoanalysen durch, um Schwachstellen und Bedrohungen zu identifizieren. - Entwickeln Sie eine Cybersicherheitsstrategie, die auf den identifizierten Risiken basiert. ### 2. Vorfallmeldung - Implementieren Sie Mechanismen zur Erkennung und Reaktion auf Sicherheitsvorfälle. - Melden Sie bedeutende Vorfälle innerhalb von 24 Stunden nach der Entdeckung (erste Benachrichtigung) und einen detaillierten Bericht innerhalb von 72 Stunden an die zuständigen Behörden. ### 3. Lieferkettensicherheit - Stellen Sie sicher, dass Drittanbieter und Partner Ihre Cybersicherheitsstandards erfüllen. - Bewerten und mindern Sie Risiken, die mit Abhängigkeiten in der Lieferkette verbunden sind. ### 4. Technische und organisatorische Maßnahmen - Verwenden Sie Best Practices der Branche für Netzwerk- und Systemsicherheit (z. B. Verschlüsselung, Firewalls, Endpunktsicherheit). - Aktualisieren und patchen Sie regelmäßig Systeme, um Schwachstellen zu minimieren. - Führen Sie Schulungen für Mitarbeiter durch, um Bewusstsein zu schaffen und menschenbedingte Risiken (z. B. Phishing) zu verringern. ### 5. Geschäftskontinuität und Notfallwiederherstellung - Etablieren und testen Sie einen Business Continuity Plan (BCP) und eine Notfallwiederherstellungsstrategie. - Stellen Sie sicher, dass kritische Systeme im Falle einer Störung schnell wieder in Betrieb genommen werden können. ### 6. Zugriffsmanagement - Implementieren Sie strikte Access-Management-Richtlinien, um den Zugriff auf Software und Daten zu kontrollieren. - Verwenden Sie Multi-Faktor-Authentifizierung ([MFA](/glossary/mfa)) für sensible Systeme. ### 7. Überwachung und Prüfung - Überwachen Sie regelmäßig Netzwerke auf verdächtige Aktivitäten. - Führen Sie regelmäßige Audits und Penetrationstests durch, um Schwächen zu identifizieren. ### 8. Einhaltung der Melde- und Kooperationsanforderungen - Führen Sie klare Dokumentationen der Compliance-Aktivitäten. - Kooperieren Sie mit nationalen Behörden, sektorspezifischen CSIRTs (Computer Security [Incident Response](/glossary/incident-response) Teams) und der EU-Agentur für Cybersicherheit (ENISA). ### 9. Sektorspezifische Compliance - Passen Sie Ihre Sicherheitsmaßnahmen an die spezifischen Anforderungen Ihres Sektors an, da die NIS2-Richtlinie unterschiedlich auf essentielle und wichtige Unternehmen angewendet wird. ## Ein paar hilfreiche NIS2 Ressourcen: - [Current NIS2 Status and Affected Sectors](https://www.openkritis.de/eu/eu-nis-2-germany.html) - [Digital Jetzt](https://www.bmwk.de/Redaktion/DE/Dossier/digital-jetzt.html) - [NIS2 History & Timeline](https://nis2directive.eu/nis2-release-date/) ## NIS2-Compliance mit Cakewalk **‍**Cakewalk ist der neue Standard im Zugriffsmanagement, entwickelt, um Sie schnell auf den neuesten Stand in Bezug auf NIS2 und andere Cybersicherheitsanforderungen zu bringen.Wir erkennen [Shadow-IT](/glossary/shadow-it), ermöglichen Self-Service-Zugriff, automatisieren On- und Offboarding, helfen Ihnen bei der Durchführung von Zugriffsüberprüfungen und mehr. Um mehr darüber zu erfahren, wie Sie das Zugriffsmanagement verbessern können, um mit neuen Vorschriften compliant zu bleiben, nehmen Sie noch heute Kontakt auf.Was haben Sie unternommen, um sich auf NIS2 vorzubereiten? Beteiligen Sie sich an der Diskussion auf LinkedIn oder nehmen Sie Kontakt auf, um Ihre Meinung zu teilen! --- # EU: Wake up and Get Ready for NIS2 _17. October 2024 was the goal date that landmark legislation, known as the Network and Information Security Directive (NIS2), should have been implemented for member states; but in a plot twist, many EU countries are behind schedule, including the economic titans of the EU,  Germany and Fr_ By Johannes Keienburg, CEO & Founder Published: 2025-01-29 Source: https://www.cakewalk.security/blog/nis2-in-eu --- 17. October 2024 was the goal date that landmark legislation, known as the Network and Information Security Directive ([NIS2](/glossary/nis2)), should have been implemented for member states; but in a plot twist, many EU countries are behind schedule, including the economic titans of the EU, Germany and France. So given this extra time, the question remains — why haven't you taken steps to become compliant yet? The fact of the matter is the cybersecurity landscape is changing and it will have rippling effects on companies whether or not they are legally compelled to comply. Let's take a look at some of these effects and how you can play catch-up to become a model EU business. ## Excuses are Like Cabooses — Everyone's Got One. _"It doesn't apply to us""We don't have the money""We'll do it later""Cybersecurity, schmybersecurity"_ **_-_****Poor excuses** we commonly hear We've heard it all before, but excuses for noncompliance are…well, inexcusable. Even if you believe that you aren't obligated to comply,** ignorance is not a defense**; proactivity is the only way to avoid frivolous legal fines and penalties. ### ‍"...What? What is NIS2?" Oh boy. If you haven't heard of it by now, you should know that [NIS2](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) is a new directive from the EU that establishes new legal frameworks surrounding member states' cybersecurity measures. It is an update to NIS1, which functioned similarly, but NIS2 widens the scope significantly (meaning it affects more industries and types of companies), provides clearer rules, and implements new accountability measures (i.e., tougher/higher fines). While NIS1 covered core sectors such as energy, healthcare, finance, water management, and others, NIS2 casts a wider net — see below for more details. ### ‍"NIS2 compliance is too expensive" You know what's more expensive? The consequences of noncompliance. It's understandable that smaller companies may not have the resources to upgrade their cybersecurity infrastructure and that staff training is time consuming and costly. However, considering that the [average cost of a data breach](https://www.csoonline.com/article/567697/what-is-the-cost-of-a-data-breach-3.html) companies is EUR 5.13 Million, and on top of that legal fines can easily amount to EUR 10 Million or more, chances are infrastructure upgrades are far less of a hassle than the alternative. Additionally, MDs can be held _personally liable _for any data breaches that occur — one of the more significant updates from NIS1 to NIS2. On top of that, in the event that a cyberattack does happen on your watch, indirect costs such as operational disruptions, reputational damage, and other financial losses have long-term consequences you may not even anticipate. But try not to worry. If you truly do not have the resources to reach state-mandated compliance requirements, many countries and local regulators offer helpful resources that help small- to mid-sized businesses improve security measures and lean into a more digital infrastructure. ### ‍"We don't have the time." We get it. Day-to-day operations take up enough time as it is and compliance efforts may not necessarily be your top priority. However, this excuse is flimsy at best and flat-out wrong at worst for three key reasons: - Cybersecurity incidents can halt your operations, sending you scrambling and costing far more time and money than you would have spent on a compliance program. - Gradual changes over time are much easier to implement than an all-at-once approach. - Outsourcing to a third-party expert can reduce your internal teams' burden. ### ‍"We don't care about cybersecurity." Well, cybersecurity cares about you. Downplaying its significance, even for smaller companies, is playing with fire. Sure, we hear about large-scale data breaches in news headlines and commentary pieces, but the majority of cyber attacks actually happen to smaller organizations that are less prone to prioritize security. For bad actors, medium-sized businesses are low-hanging fruit because they minimize security and are out of the public eye. The efficacy of your security infrastructure could also very well be the deciding factor on who wants to work with you. NIS2 actually emphasizes [supply chain security](/glossary/supply-chain-security) for good reason; it's because third-party vulnerabilities are one of the major sources of cyber risk. Noncompliance has as much potential to cost you new business as it does to cost your bottom line. NIS2 aims not only to protect your and your customers' data, it also protects your reputation — something you probably rely on. ### ‍"It doesn't even apply to me." Even if you weren't obligated to comply with NIS1, NIS2 has a more expansive scope that covers more sectors than previously. But considering this is the excuse we hear most frequently, let's break it down a little further. ### ‍Yes, It Probably Applies to You Too. Or it Will Eventually. The new list of industries affected by NIS2 includes: - **Energy**: Electricity, oil, gas, and others - **Transportation:** Logistics providers (including postal/courier services), as well as air, rail, water, and road transit companies - **Banking: **Any financial service or credit institution - **Healthcare: **Care providers, labs, and hospitals - **Essential services:** Companies that handle potable water, waste treatment/disposal, data centers, domain service providers, government entities at both regional and national levels, and more. - **Food production: **Any company that processes or distributes food products. - **Manufacturing: **Any manufacturer that deals with chemicals, medical devices, or pharmaceuticals. - **Digital services: **This is extremely broad and far-reaching. It includes social networks, cloud services, online marketplaces, search engines, and any other service that is offered digitally. NIS2 also categorizes companies into Essential and Important, according to industry and size. You can read more about the [designations here](https://nis2directive.eu/who-are-affected-by-nis2/). This new scope is estimated to affect [100,000 companies EU-wide](https://www.essendi.de/en/nis-2-what-businesses-need-to-know-right-now/). Companies with [50 or more employees](https://nis2directive.eu/who-are-affected-by-nis2/) and that have an annual turnover exceeding EUR 10 Million will wind up being subject to compliance regulations. So if you plan on growing your business in the future, you should start planning for NIS2 sooner than later. Last but not least, your customers might be impacted by NIS2 and will want their suppliers to be compliant too. We actually see this a lot in the industry… We said it before and we'll say it again: **Noncompliance can cost you potential business if other companies require it of their vendors or supply chain.** That's why we say yes, it probably applies to you too, or at least it will eventually. ## NIS1 vs. NIS2: What's Changed NIS2 is an upgrade of the existing NIS, which implements stricter requirements, a wider scope of companies affected, and heavier penalties for noncompliance. Some of the new requirements include, but are not limited to: - **Tighter incident reporting timelines**: Cyber incidents must be reported within 24 hours with follow-up reports after 72 hours. - **Business continuity and crisis management plans:** Now required for applicable businesses. - **Supply chain security and third-party risks:** Companies are obligated to actively assess and address cybersecurity measures within their vendors. - [**Zero-trust**](/glossary/zero-trust)**: **More frequent user verification processes to heavily control technology access. And don't you worry, in addition to new, hefty fines, NIS2 also mandates personal liability for management bodies like executives and company boards — a major change that should surely get leadership on board with compliance updates! ## NIS2 Steps You Should've Taken Yesterday. But There's Still Time. ### This entire process could take up to a year, so the sooner you start, the better!1. Governance and Risk Management - Appoint a responsible person (or team) for NIS2 compliance. - Conduct regular **risk assessments** to identify vulnerabilities and threats. - Develop a **cybersecurity strategy** aligned with identified risks. ### 2. Incident Reporting - Implement mechanisms for detecting and responding to security incidents. - Report significant incidents to the relevant authorities within **24 hours of detection** (initial notification) and a detailed report within 72 hours. ### 3. Supply Chain Security - Ensure that third-party suppliers and partners meet your cybersecurity standards. - Evaluate and mitigate risks associated with supply chain dependencies. ### 4. Technical and Organizational Measures - Use industry best practices for **network and system security** (e.g., encryption, firewalls, endpoint security). - Regularly update and patch systems to minimize vulnerabilities. - Conduct **employee training** to build awareness and reduce human-related risks (e.g., phishing). ### 5. Business Continuity and Disaster Recovery - Establish and test a **business continuity plan (BCP)** and disaster recovery strategy. - Ensure critical systems can quickly resume operation in the event of disruption. ### 6. Access Management - Implement strict [access control](/glossary/access-control) policies to limit data access to authorized personnel only. - Use [multi-factor authentication](/glossary/mfa) (MFA) for sensitive systems. ### 7. Monitoring and Auditing - Regularly monitor networks for suspicious activity. - Conduct periodic audits and penetration testing to identify weaknesses. ### 8. Compliance with Reporting and Cooperation Requirements - Maintain clear documentation of compliance activities. - Cooperate with national authorities, sectoral CSIRTs (Computer Security [Incident Response](/glossary/incident-response) Teams), and the EU Cybersecurity Agency (ENISA). ### 9. Sector-Specific Compliance - Tailor your security measures to meet the specific requirements of your sector, as the NIS2 directive applies differently to essential and important entities. ## ‍Helpful NIS2 Resources to Get You Back on Track - [Current NIS2 Status and Affected Sectors](https://www.openkritis.de/eu/eu-nis-2-rce-directive.html) - [NIS2 History & Timeline](https://nis2directive.eu/nis2-release-date/) ## ‍Turn NIS2 Compliance into a Cakewalk Cakewalk is the new standard in access management, designed to get you up-to-speed on NIS2 and other cybersecurity requirements. We eliminate [shadow IT](/glossary/shadow-it), facilitate self-service access, automate on- and offboarding, help you run [access reviews](/glossary/access-review), and more. To learn more about how you can enhance access management in order to stay compliant with new legislation, get in touch today. What have you done to prepare for NIS 2? What are your thoughts? Join the conversation on LinkedIn or get in touch to share! --- # Uncovering and Fixing Shadow IT _For a second, imagine the employees in your company can rent and lease cars at any time. They do this directly, without informing anyone. Still, they do it in the name of the company._ By Johannes Keienburg, CEO & Founder Published: 2024-07-22 Source: https://www.cakewalk.security/blog/uncovering-and-controlling-shadow-it --- - Over 60% of the apps used in companies are [Shadow IT](/glossary/shadow-it). - Because it's impossible to protect what you don't know, Shadow IT has become _the_ No. 1 challenge for modern IT and Security teams:Over 80% of security breaches are identity-related, largely driven by Shadow IT. - The more access identities have, the more imminent are Insider and Outsider Threats as well as Vendor Risks. For a second, imagine the employees in your company can rent and lease cars at any time. They do this directly, without informing anyone. Still, they do it in the name of the company. Some employees take sensitive documents with them into the cars—and just leave them there. Some people rent multiple cars but don't really use them. Some cars are just parked and never returned. Additionally, most people use the same key for all their cars—so if you have one key, you get access to several other cars, including the sensitive documents. And you, as the central person in charge, have lost control—which is not your fault at all. This is a scenario that no company in the world would ever accept. Yet, companies do accept the very same thing with regards to the apps their employees access. That's why Shadow IT is the No. 1 challenge for modern IT and security teams. ## 1: Why Shadow IT is exploding Up to **60%** of the software used in companies is unknown: There are three key reasons why Shadow IT is out of control in almost every fast-moving company. ### There is an app for everything With the explosion of SaaS apps, APIs, LLMs, etc. there is a tool for everything. Marketing, Sales, Product, Design, Engineering, DevOps, Finance, HR, Operations, Project Management, Legal—every function is literally leveraging apps. This vast availability enables employees to find and use applications that meet their specific needs—increasing productivity. But this comes at a high cost: the more applications available, the greater the visibility challenge for IT & Security teams. ### Distributed access It's not just that there's an app for everything; the way we access these apps has also significantly changed: Nowadays, employees directly access and introduce applications, which is a fundamental paradigm shift in IT. In other words, BYOD (”Bring Your Own Device”) has evolved into "Bring Your Own App." And IT & Security are in the dark. This explicitly includes the vast amount of freemium apps that are introduced also without finance knowledge—and an unknown free app is the same security risk as a paid unknown app. As a consequence, every employee has become a "little IT admin", managing tools, granting access, and revoking permissions. That means: IT security and compliance have become distributed responsibilities. However, most employees lack the expertise to contribute to this responsibility—which is not their fault. ### Lack of security knowledge Employees are now responsible for important aspects of IT security and compliance but lack the required security expertise. Still, they should manage the approval and removal process for the apps they own. They should check security settings like [MFA](/glossary/mfa) and ensure that no sensitive data is stored in their applications without permission. How can employees accurately handle these responsibilities if they are not trained in security? ## 2: Why Shadow IT is a major security and compliance issue [Over 80% of security breaches are identity-related](https://www.verizon.com/business/resources/reports/dbir/2022/summary-of-findings/), and Shadow IT significantly drives these risks. The more access identities have, the higher the risk of an incident. ### How Shadow IT becomes a security threat A very simple but very true rule in security says that you cannot protect what you do not know. This means that tools unknown to IT cannot be properly secured. Generally speaking, there are three areas where Shadow IT increases the likelihood of a security incident: #### Increased Insider Risks due to a lack of monitoring Companies with a large amount of Shadow IT are specifically prone to Insider Risks. Insider risks originate from within a company and can be employees, contractors, or partners - essentially everyone with access rights. There are different types of insider threats - malicious or unintentional: - Malicious insider: An insider is intentionally leaking sensitive data. - Negligent insider: Data is being leaked due to careless behavior, e.g., employees uploading sensitive data to a non-secure database. - Accidental insider: An employee is clicking on a phishing email, leading to a malware infection or a breached password. Due to the inherent trust and access granted, Insider Risks are specifically challenging to detect. The equation is simple: the more access points created by unknown tools, the higher the Insider Risk—whether it be a malicious or unintentional threat.Why? Because IT teams cannot ensure that [single sign-on](/glossary/sso) (SSO), two-factor authentication (2FA), or data loss prevention (DLP) are activated on applications they are not aware of—just to mention a few typical examples. #### Outsider risks in dormant accounts Dormant (i.e. inactive) accounts are a typical consequence of Shadow IT and pose a significant risk. These accounts can belong to: - Employees who have stopped using a tool. - To former employees who have left the company and whose access has not been removed (as it was Shadow IT). Dormant accounts are a typical entry point for outsiders. Hackers can gain access to these accounts through methods like brute forcing. Why are dormant accounts so critical when it comes to outsider activities? The lack of oversight of dormant accounts means security alerts or unusual activities may go unnoticed, giving hackers more time—and time is critical in security. Once hackers gain access via dormant accounts, they often use these entry points to infiltrate other software and systems within a company, moving laterally through the network and potentially causing extensive damage. That’s why Shadow IT is a strong driver of Outsider Risks. #### Vendor Risks When employees use unauthorized tools, they may store sensitive data on platforms that do not comply with the company's security standards. Coming back to the comparison with rental cars at the top: imagine a company has a policy that employees can only rent cars that have a valid technical certificate and that are properly registered—but nobody actually takes that into account. That’s a vendor risk. If employees e.g. store data on tools with insufficient security posture, these tools might have inherent data leakages—putting data at risk. Since IT and Security teams are unaware of these Shadow IT applications, they cannot apply any internal protective measures—making Shadow IT a typical driver of Vendor Risks. ### Recent data breaches Recent data breaches have underscored the severe risks associated with Shadow IT and shadow data. For instance, [Santander](https://www.bbc.com/news/articles/c6ppv06e3n8o) and [Ticketmaster](https://www.theverge.com/2024/6/3/24170876/snowflake-ticketmaster-santander-data-breach-details) experienced significant breaches in 2024 linked to unauthorized access through the data cloud provider Snowflake. The Santander breach impacted 30 million customers and employees, compromising account details and credit card numbers. The Ticketmaster breach affected 560 million customers. Both incidents were traced back to a dormant demo account from a former Snowflake employee, highlighting how inactive accounts can become critical vulnerabilities if not properly managed and deactivated. Similarly, the 2024 breach at AT&T affected 73 million customers, exposing sensitive information such as names, addresses, phone numbers, and Social Security numbers. Hackers known as ShinyHunters accessed data that had been stored since 2019, releasing it on the dark web. Initially, AT&T denied the breach, but later confirmed the data's legitimacy when user passcodes were found in the leaked archive, forcing a reset of 7.6 million current accounts. Again, you can’t protect what you don't know … ### Shadow IT, certifications, and GDPR Security breaches are one negative consequence of Shadow IT—non-compliance with your certifications and regulations is another. #### Certifications Companies certified under [ISO 27001](/glossary/iso-27001) or [SOC 2](/glossary/soc-2) cannot afford a significant amount of Shadow IT, as this would breach their [access control](/glossary/access-control) policies. Non-compliance with these certifications can lead to financial damages, as most companies are certified to meet the security standards required to service their customers. #### GDPR‍ Also, unauthorized applications lacking [GDPR](/glossary/gdpr) standards can become an issue for companies. If employees use non-GDPR compliant apps and store customer data on these apps, your company could be found in violation of GDPR regulations. If your IT team is not aware of this, they can't take any proactive measures to prevent these violations. ## 3: How to fix Shadow IT Given the distributed nature of access to apps, APIs, and LLMs, tackling Shadow IT is very complex. However, IT and Security teams are not helpless. They can fight back and regain control with effective Shadow IT management. By far, the most impactful way to fight the origins of Shadow IT is by implementing proper Access Management. ### Asset Inventory - **Establish an Asset Inventory:** List all your apps in an asset overview. Differentiate between sanctioned and non-sanctioned applications, with sanctioned apps being your critical apps. Every employee should contribute to the asset inventory. - **Step 1: Hands-on Approach for Younger Companies:** Start with a simple, hands-on approach. Use a spreadsheet to track applications. While this method is not scalable in the long term, it's a good start for smaller or younger companies. - **Step 2: Use Software Solutions:** Utilize software solutions that provide visibility into all apps. These tools can automatically discover and categorize applications used within your organization. ### Employee-friendly Access Controls - **Implement Access Controls:** Establish a robust Access Management process. Strict access controls are essential to manage and prevent further Shadow IT. This process should follow the principle of [least privilege](/glossary/least-privilege)—i.e., employees only get access to the very applications they really need, avoiding over-provisioning. - **Winning employees:** Any access management approach is worthless if you can’t ensure that your employees adhere to it. Here’s how to achieve this:Explain to your employees why access controls matter; make this a management priority! - Implement an approach that is easy to follow. If you create a cumbersome process monster, people will not follow it and might even proactively work against it. - Incorporate value for employees. While you want to limit access and implement least privilege, help your teams get access to all actually needed tools as quickly and seamlessly as possible. This will drive employee compliance with your process. ### RBAC - [**Role-Based Access Control**](/glossary/rbac)** (RBAC):** Use RBAC to grant employees access only to the apps they need for their roles. This minimizes the risk of unauthorized access and ensures that permissions are aligned with job responsibilities. - **Time-Based Access:** For any exception from the RBAC, users should in general only get time-based access. ### Access Reviews - **Run regular **[**Access Reviews**](/glossary/access-review)**: **Conduct regular access reviews, ideally quarterly. These reviews are a valuable way to remove unused seats and ensure access permissions are aligned with current job roles and responsibilities. Often overlooked, access reviews do not only significantly enhance your security posture but also reduce SaaS costs by eliminating unused subscriptions. ### Clear Offboarding Process - **Offboarding Checklist:** Implement a clear offboarding checklist. Implement a policy that every single seat has to be removed in any user offboarding. Normally, either team leaders or app owners have to implement this—with IT being in charge of the overall process. - **Sync visibility and offboarding:** Use your asset inventory (see above) as your baseline. No visibility no proper offboarding! - **Automated Deprovisioning:** Use automated deprovisioning tools to revoke access to all company resources immediately when an employee leaves the organization. This is step 2 though.