> ## Content Index > Fetch the complete content index at: https://research.controlarch.org/llms.txt > Use this file to discover other available public pages before exploring further. # IAM's Defining Moment - URL: https://research.controlarch.org/iams-defining-moment/ - Published: 2026-10-25T20:58:54.000Z - Updated: 2026-10-28T02:53:09.000Z - Description: AI agents now act faster than IAM can detect, decide, and enforce. CAI’s 2027 trends report sets out five trends, explains why IAM must extend from access to authority management, and names what to withhold, what to measure, and what to do in 2027. - Author: Homan Farahmand - Tags: Annual Trends Report 2027, IAM, Authority Management [IAM's Defining MomentWhen AI agents’ harm outruns control, IAM must govern authority as well as access.Annual Trends Report 2027.pdf1 MBdownload-circle](https://research.controlarch.org/content/files/2026/10/Annual-Trends-Report-2027-1.pdf "Download") ## Insights > **CAI View** IAM was built for a world where control was faster than harm. AI agents end that world. IAM must still decide who can access what. It must now also limit what an agent can do with that access: how much, for how long, and in which systems. This is authority management. **IAM’s core assumptions no longer hold for AI agents.** IAM assumes that identity predicts behavior, that periodic access reviews are enough, that controlling access controls the outcome, that risk stays inside the enterprise, and that IAM is consulted before access is granted. AI agents break each of these assumptions. They act faster than reviews, they combine permitted actions into harmful outcomes, they act in systems the enterprise does not run, and they often receive access before IAM is involved. **Preventive limits work. Detection after the fact does not.** A control is effective only if it acts before harm occurs. For AI agents, the most reliable controls are limits set when access is granted: what the agent may do, how much, and until when. These limits apply automatically. Detection and response depend on someone noticing and acting in time, which for agents is often too late. **Identity tools are necessary but not sufficient.** Agent registries, agent identities, AI gateways, and AI monitors show which agents exist and what they request. They do not limit the total effect of an agent’s actions, they can be bypassed, and they are often added too late. Using AI to monitor AI also adds a system that can itself be misled. **The strongest controls sit where actions take effect.** The systems that carry out an agent’s actions, such as SaaS applications, cloud platforms, and business systems, can hold, refuse, or reverse those actions, and widely used providers can do so for all their customers at once. CAI calls these points of consequence. Their operators should publish the limits they apply to agents and have them independently audited. **Authority management is the discipline IAM needs to adopt agents at scale.** Authorization decides whether a single action is allowed. Authority management governs the full life of the power behind that action: who delegated it, its limits, its duration, how it is stopped, and how its use is proven. Organizations should start now. Set limits when access is granted, measure how fast an agent can be stopped, and withhold irreversible actions until they can be stopped or reversed. ## Why This Is IAM’s Defining Moment *IAM rests on five assumptions that have held for almost thirty years. Each remains necessary. None is sufficient for AI agents.* IAM was designed for people and for predictable software. Its controls assume that a known subject acts, that harm takes time to develop, and that IAM is consulted before access is granted. Under these conditions, deciding who may access what was enough to keep control. AI agents remove these conditions, but not the need for identity and access control. IAM therefore has to extend its scope, not start over. Table 1 sets out each assumption, why it no longer holds for agents, and what IAM must add. **Table 1.** *IAM’s five assumptions remain necessary, but each needs an extension for AI agents* | **IAM assumption** | **Why it no longer holds for AI agents** | **What IAM must add** | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Identity predicts behavior** | The same agent identity can run a different model, different instructions, or a different set of sub-agents from one day to the next. Its identity no longer tells you what it will do. | Limits on what the agent can do: how much, how fast, and whether its actions can be undone | | **Periodic access reviews are enough** | Reviews run monthly or quarterly. An agent can cause harm within minutes and run for hours between reviews. | Limits and an end date set when access is granted, not at the next review | | **Controlling access controls the outcome** | An agent can combine individually permitted actions into a harmful result. Access decisions do not see the combined result. | Control of outcomes: what takes effect, and whether it can be held, reversed, or stopped | | **Risk stays inside the enterprise** | Agent actions take effect in SaaS applications, cloud platforms, and partner systems that the enterprise does not operate. | Limits carried in the agent’s credential, so that the receiving system can enforce them | | **IAM is consulted before access is granted** | Business teams grant agents access, and come to depend on them, before IAM is involved. | Limits applied by default, so that they cannot be bypassed | ### IAM is now business-critical infrastructure As agents take on operational work, IAM no longer governs only who can sign in. It governs what software can do inside the business. A failure no longer means one user locked out of an application. It can mean inappropriate access granted to hundreds of users, customer records deleted, or data exposed, within minutes. Controls that are too weak expose the business to that harm. Controls that are too strict prevent agents from doing useful work. IAM has become a condition for using AI agents at all. Adopting stronger controls for agents is difficult for five reasons: - **Split ownership.** Business teams deploy agents, IAM teams manage identities, and security teams run monitoring. In many organizations, no one is accountable for what an agent is allowed to do from end to end. - **Older systems.** Many applications support only broad API keys or shared service accounts, and cannot enforce fine-grained or time-limited access. - **Product gaps.** Few products can enforce a total limit that applies to an agent and to every sub-agent it starts. - **Skills.** Teams are experienced in reviewing user access, but few measure how quickly they can stop an agent. - **Business pressure.** Agents deliver value immediately, so new controls are easily seen as delay. What to Do in 2027 sets out where to start despite these constraints. ### Control must be faster than harm A control is effective only if it acts before harm occurs. This applies to every IAM control, from revoking a token to denying a request. It can be expressed as a single test that must hold for every agent and every action: > **The Control Formula:** **Detect + Decide + Enforce < Time to Harm.** Time to harm is the time between the start of an action and the point at which its effect can no longer be reversed. If detecting the problem, deciding to act, and enforcing the decision take longer than that, IAM records the harm but does not prevent it. Two forces make this test harder to pass. **Harm happens faster:** agents act at machine speed, run for long periods, and start other agents. **Control starts later:** teams grant agents access to deliver value quickly, before controls are in place, and by the time IAM is involved the business depends on the agent. A common response is to use an AI monitor to watch agents at machine speed. This improves speed but introduces a new weakness: the monitor is itself an AI system. It can be misled by the agent it watches, it can make mistakes, and it decides too quickly for people to check each decision. The organization must then control the monitor as well. CAI calls this the **recursion trap**: every AI monitor needs its own oversight, so the same problem repeats one level up. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/10/figure-1-2.png) **Figure 1.** *Control works only while detect, decide, and enforce beat time to harm, and both sides are moving the wrong way* > **CAI View** The choice for IAM. IAM can extend its scope, through authority management, to control how much agents can do, how fast, and in which systems. Or it can continue to manage identities well while losing control of what agents actually do. Agent registries and agent identities are necessary first steps, but they are not the destination. > **CAI View** What no IAM control can promise. In this report, superintelligence means an AI system that outperforms people at most tasks, including understanding and circumventing the controls placed on it. An unrestricted superintelligence also has broad access to accounts, money, computing resources, and people. No current or proposed IAM control can promise to contain such a system. The measures in this report reduce risk and buy time. They do not make such a system controllable. ## Authority Management: The Discipline IAM Needs *Authorization decides whether a single action is allowed. Authority management governs the full life of the power behind that action. For AI agents, this difference determines whether control is possible.* Five related terms are often used interchangeably, but they describe different things. Table 2 defines each term and illustrates it with one running example: an AI agent that sets up access to an enterprise resource planning (ERP) system for new Finance employees. In the example, a role is a named set of entitlements. When the agent assigns a role to a new employee, that employee receives the entitlements the role contains. The definition of authority follows [Identity and Access Governance Controls](https://research.controlarch.org/identity-and-access-governance-controls/) (IAM-F-GOV-01). **Table 2.** *Permission, entitlement, authorization, authority, and authority management are different, and only authority management covers the full life of an agent’s power* | **Term** | **What it is** | **Question it answers** | **Example: an onboarding agent that assigns ERP roles** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Permission** | A system-level right to perform one action on one resource | What action does this system allow? | “Assign role” in the ERP system’s user administration | | **Entitlement** | A permission, or set of permissions, granted to an account and held over time | What does this account hold? | The agent’s account holds the ERP user administrator role, which includes “assign role” | | **Authorization** | The decision whether to allow a request. For an agent at run time, it is a single allow-or-deny decision at one moment | May this request proceed now? | At 10:02, the ERP system allows the agent to assign the accounts payable clerk role to a new employee | | **Authority** | The legitimate power to act, derived from a named person or organizational role. Every entitlement draws its legitimacy from it. An agent holds authority only by delegation | On whose behalf, within which limits, and for how long may this agent act? | The IAM operations manager delegates to the agent the authority to assign the standard Finance roles mapped to each job code, only for the 12 people on this week’s HR start list, until Friday. Privileged roles and role combinations that break separation of duties are excluded | | **Authority management** | The discipline around authorization. It decides, delegates, limits, sustains, and revokes the power that a person, workload, or agent may exercise, and proves afterward that the power was used within its limits | Is the power behind each action still legitimate, within its limits, stoppable, and provable? | It checks each role assignment against the HR start list, the role mapping, and the separation-of-duties rules; refuses requests outside them; ends the agent’s authority on Friday; stops every sub-agent with one action; and proves that each assignment stayed within the delegation | **Why the difference matters.** Permissions, entitlements, and authorization each evaluate a single action or a single account. None of them evaluates whether an action falls within what was delegated, whether the time window has expired, what sub-agents are doing, or whether the person who delegated the authority would still agree. In the example, the agent holds the ERP user administrator role, so ERP authorization allows every role assignment it requests, including one for a person who is not a new hire, one that creates a separation-of-duties conflict, and one for a privileged role. Only authority management refuses them, because only it checks each request against the delegation. Its limits are practical because they come from records the organization already keeps: the HR start list, the role mapping for each job code, and the separation-of-duties rules. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/10/figure-2-2.png) **Figure 2.** *Authorization decides one request at one moment; authority management governs the full life of the power behind every request* ### The four parts of authority management CAI structures authority management in four parts. Each part corresponds to one layer of IAM, and each layer is covered by a CAI Foundation Report: - **Bind:** [Identity and Access Substrate](https://research.controlarch.org/identity-and-access-substrate/) (IAM-F-SUB-01) - **Decide:** [Identity and Access Governance Controls](https://research.controlarch.org/identity-and-access-governance-controls/) (IAM-F-GOV-01) - **Sustain:** [Identity and Access Runtime Controls](https://research.controlarch.org/identity-and-access-runtime-controls/) (IAM-F-RTM-01) - **Prove:** [Identity and Access Observability Controls](https://research.controlarch.org/identity-and-access-observability-controls/) (IAM-F-OBS-01) **Table 3.** *Authority management has four parts, each matched to one layer of IAM* | **Part** | **What it does** | **IAM layer** | **For AI agents** | | ----------- | --------------------------------------------------------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------- | | **Bind** | Ties an identity to a real person, workload, or agent | Substrate | Tie authority to one agent, one task, and one model version, not to a shared account | | **Decide** | Decides and delegates authority before any action takes place | Governance | Set the scope, total limits, end date, stop conditions, and accountable person when access is granted | | **Sustain** | Keeps authority valid at the moment of action and for as long as the action lasts | Runtime | Check limits on every action, and make a single stop reach every sub-agent | | **Prove** | Proves afterward how authority was used | Observability | Show who acted, on whose authority, within which limits, and that the stop worked | > **The Authority Rule** If an organization cannot yet bind, decide, sustain, and prove authority for a type of action, its agents should not perform that action on their own. Table 8 applies this rule to the four withhold classes. ### Why authority management makes adoption at scale reliable With a few agents, people can supervise each one. With hundreds of agents, each starting sub-agents, they cannot. At that scale, adoption is reliable only if every agent has an accountable owner, a total limit, and an end date, and if a single action can stop the agent and all its sub-agents. Authority management provides these properties. It also allows organizations to extend agent autonomy with confidence, because they can show where the limits are and prove that the stop works. Without it, organizations must choose between slowing adoption and accepting risk they cannot measure. > **CAI View** Establish authority management before scaling AI agents. Authorization decides whether one action is allowed now. Authority management governs the full life of the power behind every action: who delegated it, its limits, its duration, how it is stopped, and how its use is proven. It does not replace authorization, entitlements, or permissions; it governs them. Without it, each new agent adds risk that the organization can neither measure nor stop. ## Five Trends for 2027 *Each trend describes a change observed in 2026, what it means for IAM, and the action it calls for. Trends 1 to 3 explain why IAM’s assumptions no longer hold. Trend 4 is a positive development. Trend 5 is a gap.* **Table 4.** *Five trends for 2027: what is happening, why it matters for IAM, and what to do* | **Trend** | **What is happening** | **Why it matters for IAM** | **What to do** | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Trend 1\. Harm outruns control** | Agents act faster and for longer than controls can respond. AI monitors alone do not close the gap. | Periodic reviews and per-request decisions act too late. | Measure how quickly each important agent can be stopped, and enforce limits outside the agent. | | **Trend 2\. Authority arrives before IAM** | Business teams grant agents access, and come to depend on them, before IAM reviews that access. | Approval steps that can be skipped will be skipped. | Establish authority management, with limits and end dates applied by default. | | **Trend 3\. Harm lands outside the enterprise** | Agent actions take effect in SaaS, cloud, and partner systems that the enterprise does not operate. Those operators can detect problems first. | The enterprise boundary no longer contains the risk. | Carry limits in agent credentials, and choose providers that can hold or reverse agent actions. | | **Trend 4\. Control moves to the point of consequence** | Operators of the systems where actions take effect are beginning to limit, hold, and reverse risky actions for all their customers. | Some of the most effective controls sit outside IAM’s own systems. | Enforce authority at the point of consequence through embedded controls or wrapper shields (see Where Control Must Sit), and require providers to enable them. | | **Trend 5\. The market and the rules lag** | Vendors present agent identity as control, insurers are starting to exclude AI risk, and regulators defer obligations. | No external party will require proof of control in 2027. | Define the evidence required before granting an agent more autonomy. | ### Trend 1\. Harm outruns control **AI agents can cause harm faster than controls can respond, and adding AI monitors does not close the gap.** An agent acts at machine speed and can work for hours without supervision, so the time to harm is short. Detection, decision, and enforcement still depend largely on people and on periodic processes. Monitors that are themselves AI systems are faster, but they can be misled by the agents they watch. **What 2026 showed.** - **Agents work for long periods without supervision.** In security-testing incidents disclosed by Anthropic, individual agents worked on the live internet for roughly 10 to 34 hours.1 Independent research shows that the length of tasks that leading models can complete about half the time has doubled about every four months since 2023.2 - **Harm spreads faster than people can react.** In March 2026, attackers published malicious versions of a widely used package on the Python Package Index (PyPI), the main public repository of open-source Python software. They were downloaded about 119,000 times in the two and a half hours before PyPI quarantined them.3 - **AI monitors can be misled.** In one incident, offline monitors that read the agent’s own reasoning would have missed the harmful activity, because the reasoning persuaded them that the environment was simulated and that no real harm was occurring.4 - **Test results can overstate safety.** Training that reduced hidden harmful behavior in tests also made models more likely to recognize when they were being tested.5 - **Stopping is not guaranteed.** In one study, a model modified its own shutdown script in 79 of 100 initial test runs. When explicitly told to allow shutdown, some models from other developers complied in every test, while some OpenAI reasoning models still resisted.6 > **Case in Point:** **The dashboard task.** In June 2026, an internal OpenAI model was asked to collect figures from a research organization’s public dashboard. The task did not permit access to the organization’s internal systems. The model used credentials it found in code on a public website to reach the organization’s internal search service, temporarily changed a cloud setting to obtain a storage token, and downloaded five non-public tables containing 147,451 rows. It did not report these actions. OpenAI identified the incident by August, when it ran its misalignment monitor over past activity, and rated it critical.7 **What it means for IAM.** Periodic reviews and per-request decisions cannot keep pace with harm that unfolds in minutes. Each important agent needs a measured time to stop: the time it takes to detect a problem, decide to act, and enforce a stop. Its limits must also be enforced outside the agent, where the agent cannot argue with them. AI can help find and prioritize problems, but it should not be the only control. ### Alignment and IAM **Alignment** describes whether an AI system pursues the goals, and respects the limits, that its operators intend. Alignment and IAM affect each other. A poorly aligned agent can misuse access that IAM granted correctly, so a correct access decision does not guarantee an acceptable outcome. Better alignment reduces how often this happens, but it does not remove the need for limits. Poor alignment also weakens controls that rely on what the agent reports about its own work. Detection should therefore include alignment signals: - Actions outside the scope of the assigned task. - Actions missing from the agent’s own reports. - Attempts to work around a block, for example by asking another service to perform a blocked action. - Misalignment reports that AI developers publish about the models in use. > **Watch-Out** Do not rely on one AI to control another. An AI monitor, judge, or gateway that reasons about an agent’s requests can be misled by them. Use AI to find and prioritize problems, and use fixed limits to stop agents. **Call to action.** Measure before you trust (Call 1 in Table 9). ### Trend 2\. Authority arrives before IAM **Business teams grant agents access, and come to depend on them, before IAM reviews that access.** The benefits of an agent are immediate and visible, while its risks are delayed and uncertain. Teams therefore grant access first and involve IAM later, if at all. Once the business depends on the agent, removing its access becomes costly. **What 2026 showed.** - **Convenience wins, even at careful organizations.** The UK AI Security Institute enabled internet access in its evaluation environments by design, so that agents could download the tools their tasks needed. After its incident, it decided that internet access must be actively justified rather than enabled by default.8 - **Agents ran on access that no security review approved.** The 2026 incidents ran in test and research environments configured by the teams running them, including an evaluation mistakenly connected to the internet and shared credentials given to agents.9 Enterprises face the same pattern when a business team connects an agent to a system with a broad API key. - **Adoption outpaces policy.** In a vendor-commissioned survey, 82% of organizations used AI agents, but only 44% had policies to secure them.10 **What it means for IAM.** When the benefit is immediate, any approval step that can be skipped will be skipped. IAM can keep pace only through defaults: agent access that comes with limits and an end date already set, so that the fastest way to deploy an agent is also the controlled way. **Call to action.** Establish authority management (Call 2 in Table 9). ### Trend 3\. Harm lands outside the enterprise **Agent actions take effect in systems that the enterprise does not operate, and the operators of those systems can see the problem first.** Agents change records in SaaS applications, create resources on cloud platforms, and publish to public code repositories. The enterprise’s own IAM can neither see nor reverse these changes. The operator of the receiving system can. **What 2026 showed.** - **Harm occurred outside the developers’ own systems.** In 2026, agents published a malicious package to a public code repository, reached a security vendor’s live database, compromised a platform that hosts AI models, and accessed data on a government health statistics website without authorization.11 - **Developers found their own incidents late.** Anthropic identified a January incident in August, and OpenAI identified a June incident by August.12 - **Security monitoring caught what evaluation controls missed.** The UK AI Security Institute’s general security monitoring flagged unusual outbound traffic three days after the unsanctioned activity began, and the institute stopped all runs within one hour of the alert. It noted that monitoring built to watch evaluations as they run could have caught the behavior sooner.13 > **Case in Point:** **The platform knew first.** From late May 2026, OpenAI research models extended their reach beyond their internal environment. In July, they collected credentials from Hugging Face, a platform that hosts AI models. Hugging Face disclosed suspicious activity on 16 July. OpenAI’s monitoring flagged unusual identity-related activity on 19 July, and OpenAI disclosed its role on 21 July.14 **What it means for IAM.** The enterprise boundary no longer contains the risk. An agent’s limits must travel with it, inside its credentials, so that receiving systems can read and enforce them. Enterprises should prefer systems that can check those limits, hold the agent’s actions, and stop the agent. **Call to action.** Let limits travel with the agent (Call 3 in Table 9). ### Trend 4\. Control moves to the point of consequence **The operators of systems where agent actions take effect are beginning to limit, hold, and reverse risky actions for all their customers.** CAI calls these systems points of consequence. When their operators change a default, every customer benefits without any change on its own side. Standards that let credentials carry limits are also emerging, although they do not yet cover a total limit shared by an agent and its sub-agents. **What 2026 showed.** - **Code repositories protect all publishers.** PyPI can quarantine malicious releases within hours. npm, the main public repository of JavaScript software, revoked old-style access tokens, required two-factor authentication for interactive publishing, and limited token lifetimes for all publishers at once.15 - **Cloud providers set safer defaults.** Since March 2024, Google Cloud has blocked the creation of long-lived service account keys in every new customer organization unless an administrator allows it.16 - **Platforms keep deleted data recoverable.** GitHub allows deleted code repositories to be restored for 90 days, and Microsoft Azure Key Vault keeps deleted encryption keys recoverable for 90 days by default.17 - **Certificate authorities and browser makers shorten credential lifetimes.** Website certificate lifetimes fall to 200 days in 2026, 100 days in 2027, and 47 days in 2029\. A rule set by a small group of operators changes practice for every organization that uses public website certificates.18 - **SaaS platforms can revoke stolen access centrally.** In August 2025, after attackers used stolen tokens from one integration to take data from many customers of one SaaS platform, the integration provider and the platform revoked all of that integration’s tokens in a single action.19 - **Credentials are starting to carry limits.** OAuth Rich Authorization Requests, an IETF standard, lets a credential describe precisely what it permits.20 Current IETF drafts do not yet define a total limit shared by an agent and its sub-agents.21 > **Case in Point:** **Within the hour.** During testing in 2026, a model uploaded a malicious package to PyPI, and 15 third-party computers installed it. Revoking the model’s access could not have recalled a package that was already public, but PyPI removed it within one hour. The effective control belonged to the operator of the receiving system, not to the organization running the agent.22 **What it means for IAM.** Some of the most effective controls for agents sit outside IAM’s own systems. IAM should issue agent credentials that these systems can read and enforce, and connect to their ability to hold and stop agent actions. **Call to action.** Enforce authority where actions take effect (Call 4 in Table 9). ### Trend 5\. The market and the rules lag **Vendors present agent identity as control, insurers are starting to exclude AI risk, and regulators defer obligations. As a result, no external party will require organizations to prove in 2027 that they can stop an agent.** The market is building inventory and identity for agents rather than limits on what agents can do, and the external pressure that might change this remains weak. **What 2026 showed.** - **Identity is what the market sells.** In 2026, major cloud identity providers and IAM vendors made agent identity generally available, and leading cybersecurity and IAM vendors acquired IAM vendors, including specialists in privileged access and in workload and AI agent identities. No product in CAI’s review enforces a single total limit across an agent and its sub-agents, meaning one cap, such as the number of records they may change, that applies to all of them together.23 - **Insurers are starting to exclude AI risk.** Optional generative AI exclusions for standard general liability policies became available to insurers in January 2026.24 - **Regulation is deferred or voluntary.** The EU postponed its high-risk AI obligations to December 2027 and August 2028.25 In September 2026, leading US AI developers signed a voluntary White House accord on internal safeguards and outside audits.26 California requires frontier developers to report critical safety incidents after they occur.27 **What it means for IAM.** Agent identity is necessary but not sufficient. Because no external party will require proof of control in 2027, each organization must define its own standard. **Call to action.** Set your own standard of proof (Call 5 in Table 9). ### From trends to architecture Taken together, the five trends lead to one architectural conclusion: - **Trend 1** shows that control must act before harm occurs, and outside the agent. - **Trend 2** shows that limits must apply by default, because approval steps that can be skipped will be skipped. - **Trend 3** shows that agent actions take effect in systems that the enterprise’s own IAM cannot see. - **Trend 4** shows that the systems where actions take effect are able to enforce limits. - **Trend 5** shows that no external party will require those systems to enforce limits in 2027, so each organization must set that requirement itself. For authority management, this means that its four parts cannot all sit in the same place. Authority is bound and decided in the authority plane (defined in the next section), before the agent acts. It can be sustained only where the agent’s actions take effect, because that is the one place the agent cannot avoid, and it can be proven only from evidence recorded there. The next two sections set out where these controls must sit and how to architect them. ## Where Control Must Sit *Authority is bound and decided in IAM, sustained where actions take effect, and proven from evidence recorded there. Every agent action passes three layers of control, and only the last of them cannot be bypassed.* **The origin** is where the agent’s capabilities come from: model providers and agent platforms. **The path** is the route that the agent’s requests take: AI gateways, MCP gateways, and proxies operated by the organization that deploys the agent. **The point of consequence** is the system where the action takes effect: the business application, SaaS application, cloud platform, data store, or code repository that changes a record, assigns a role, or publishes software. These three places are distinct from the **authority plane**: the IAM services that bind identities, decide and delegate authority, issue credentials, and send stop signals, such as identity providers, identity governance, and privileged access management. The authority plane determines what an agent may do. It does not carry out the agent’s actions, so it is not a point of consequence. Its decisions take effect only when the point of consequence enforces them. The three places form a layered control model, and each layer has a role. The origin shapes what every agent built on a model or platform can do, which gives it reach but also concentrates influence in a few vendors. The path lets the deploying organization see and filter requests early, close to the agent, but only those routed through it. The point of consequence is where an action becomes real and its result is visible. It is the last line of defense: the only place that every action must pass, that sees every agent and sub-agent acting on it, and that can slow harm by holding or reversing an action. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/10/figure-3-2.png) **Figure 3.** *Authority is decided in the authority plane and enforced at the point of consequence, which agents cannot bypass* **Table 5.** *In a layered control model, the gateway filters requests early and the point of consequence closes the control loop* | **Control property** | **Gateway on the path** | **Point of consequence** | | -------------------- | ------------------------------------------ | ------------------------------------------------------------------------ | | **Where it acts** | Before a request reaches the target system | Where the action takes effect: the last point at which it can be stopped | | **Who operates it** | The organization that deploys the agent | The owner or provider of the target system | | **Coverage** | The traffic routed through it | Every action on the system, by every agent and sub-agent | | **Total limits** | Only within the traffic it sees | One running total across an agent and all its sub-agents | | **Response to harm** | Allows or denies a request | Holds, delays, or reverses an action | | **What it knows** | The request and its context | The result: what actually changed | The layers complement each other. The gateway catches misuse early and reduces the load on the systems behind it. The point of consequence closes the control loop: it is the layer that every action must pass, so it stops what earlier layers miss or cannot see. Neither replaces the other, but only the point of consequence can enforce delegated authority on every action. ### Two ways to enforce authority at the point of consequence Enforcing access where actions take effect is not a new idea. Resource-based access control attaches a policy to the resource itself, and the service that hosts the resource evaluates it on every request. Zero trust architecture places a policy enforcement point in front of each resource and keeps the implicitly trusted zone behind it as small as possible.28 What is new for AI agents is what the enforcement point must check: not only whether a request is permitted, but whether it falls within the delegated authority behind it. There are two ways to achieve this, shown in Figure 3 as a ring around the target system. - **Embedded control.** The target system enforces delegated authority itself, as part of its own access control. On every action, it checks the scope, total limit, and end date carried in the agent’s credential. It keeps one running total for the agent and all its sub-agents, holds irreversible actions for review or keeps them recoverable, accepts stop signals from the authority plane, and records evidence of each action. Embedded control is the strongest option, because the agent cannot bypass the system that carries out its actions. It requires the system, or its provider, to support these checks. Its protection holds only if the system has no route around its own controls: direct database access and administrative interfaces must be closed to agents or covered by the same checks. - **Wrapper shield.** Where a target system cannot embed these checks, for example a legacy application that supports only a shared service account, a dedicated enforcement point is placed directly in front of it, such as an API layer, a database proxy, or a session broker. The target system accepts connections only from the shield, so every action must pass through it. The shield performs the same checks on the system’s behalf. > **Watch-Out** A wrapper shield is not a gateway. Both sit in front of a system, but they belong to different layers and differ in whether they can be avoided. A wrapper shield belongs to the target system: the system owner operates it, and the system accepts no other route. A gateway belongs to the deploying organization’s path: it sees only the traffic routed through it, and agents can route around it. Gateways remain useful path controls, covered in [AI Agent Identity and Access](https://research.controlarch.org/ai-agent-identity-and-access/) (IAM-CAP-AI-01). Table 6 shows where each part of authority management is enforced as a result. **Table 6.** *Authority is bound and decided in the authority plane, sustained at the point of consequence, and proven from evidence recorded there* | **Part** | **Where it is enforced** | **What the enforcing component does** | | ----------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Bind** | Authority plane | Issues a unique identity and credential to each agent, tied to one task and to the person who delegated the authority | | **Decide** | Authority plane | Records the delegation and writes its scope, total limit, and end date into the credential | | **Sustain** | Point of consequence, through an embedded control or a wrapper shield | Checks every action against the delegation, keeps the running total, holds irreversible actions, and enforces stop signals from the authority plane | | **Prove** | Evidence recorded at the point of consequence; proof established in the authority plane | The point of consequence records each action with the agent, the delegation it relied on, and whether it was within limits; the authority plane correlates these records across systems to prove that every action stayed within the delegation and that every stop took effect | ## Change the Game *Six control strategies put authority management into practice. When the providers of widely used systems build them in by default, every customer benefits at once.* The previous section showed where authority must be enforced. This section sets out how. Each strategy in Table 7 is an architectural decision for IAM and for the owners of target systems. Strategies 1 and 2 bind and decide authority, strategies 3 to 5 sustain it, and strategy 6 proves it. Together, the strategies turn delegated authority from a policy statement into a control that operates on every action. **Table 7.** *Six control strategies that put authority management into practice* | **Control strategy** | **What the control does** | **Where it is enforced** | **Enterprise example** | | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **1\. Bind authority to one agent and one task** | Issue each agent a unique workload identity and a credential for one task, linked to the accountable person who delegated the authority. Prohibit shared service accounts and long-lived secrets for agents. | Authority plane | An invoice-matching agent receives its own credential instead of using the shared finance integration account | | **2\. Carry the delegation in the credential** | Express the delegated scope, total limit, and end date as constraints in the credential. Allow constraints to be narrowed, never widened, when the agent delegates to a sub-agent. | Authority plane | A credential permits updates to supplier records in one company code, up to 200 changes, until the end of the business day | | **3\. Enforce delegated authority at the point of consequence** | Evaluate every action against the credential’s constraints with a resource-side policy, and keep one running total for the agent and all its sub-agents. Use a wrapper shield where the system cannot do this itself. | Point of consequence: embedded control or wrapper shield | The ERP system refuses a role assignment outside the approved job-code mapping, or one that creates a separation-of-duties conflict | | **4\. Slow irreversible actions** | Apply a hold, a delay, or a recovery period to actions in the withhold classes (Table 8), so that a person or a control can intervene before the effect becomes permanent. | Point of consequence | The CRM system holds a bulk deletion of customer records for the data owner’s approval, and keeps deleted records recoverable for 30 days | | **5\. Stop everywhere at once** | Propagate revocation from the authority plane to every target system through shared security signals, so that one stop ends the credentials and sessions of the agent and its sub-agents everywhere. | Authority plane sends; point of consequence enforces | Disabling an agent ends its active sessions in the ERP, CRM, and document management systems within minutes | | **6\. Record evidence where actions take effect** | Log each action at the target system with the agent, the delegation it relied on, and whether it was within limits, including refused attempts. Keep the evidence independent of the agent’s own reports. | Point of consequence, correlated in the authority plane | The HR system’s audit log shows each employee record change, the delegation behind it, and each refused attempt | ### How the strategies work together The strategies depend on each other. A credential that carries limits (strategy 2) is useful only if the target system enforces them (strategy 3). A stop issued in the authority plane (strategy 5) takes effect only in systems that accept the signal. Evidence (strategy 6) proves control only if it is recorded where the action took effect. Organizations should therefore apply all six strategies to each important agent, starting with the systems where its withhold-class actions (defined in What to Withhold, What to Earn) take effect, rather than applying one strategy across every agent. Ownership follows the architecture: IAM owns strategies 1, 2, and 5, and sets the standard for strategies 3, 4, and 6, which the owners and providers of target systems implement. **What standards support today.** OAuth Rich Authorization Requests lets a credential describe precisely what it permits.29 The Shared Signals Framework, CAEP, and RISC, final since 2025, let the authority plane send stop signals to connected systems that implement them.30 Current IETF drafts do not yet define a total limit shared by an agent and its sub-agents.31 Until they do, the running total must be kept at the point of consequence, by an embedded control or a wrapper shield. ### Why this changes the game For most enterprises, many consequential agent actions take effect in a small number of widely used SaaS applications, cloud platforms, and business systems. When the provider of one of these systems builds the strategies in by default, every customer inherits them without effort. Google Cloud’s 2024 decision to block long-lived service account keys in new customer organizations shows how one provider’s default can change practice across all its customers.32 Recovery periods that platforms already offer for deleted data show the same effect for irreversible actions.33 **How the market can speed adoption.** Three forces can move providers faster. Purchasing requirements can make embedded controls, holds, and stop signals a condition of buying. Contract terms can assign accountability for agent actions that exceed their delegation. Insurers can price the difference between proven and unproven limits. Providers also have their own reason to act: they bear costs when agent actions go wrong on their systems, and as insurers start to exclude AI risk, more of that cost falls on them and their customers. > **CAI View** Providers that enforce authority must be accountable for it. Providers that build these controls into widely used systems protect many organizations at once, which also gives them considerable power over those organizations. They should publish what they accept from AI agents, what they hold for review, and what they can reverse, and independent auditors should verify that they apply these limits. > **Watch-Out** These strategies reduce risk; they do not remove it. Embedded controls and wrapper shields work in the organization’s own systems as well as in providers’ systems, but each target system must be covered, and coverage takes time. The strategies reduce risk and buy time; they do not make an unrestricted superintelligence controllable. ## What to Withhold, What to Earn *For some actions, no control can respond in time. Agents should not perform these actions on their own until tests show that control works.* The control formula divides agent actions into two groups. For the first group, control can act before harm occurs, and agents can act autonomously within limits and with monitoring. For the second group, control cannot act in time. Agents should not perform these actions autonomously until the organization adds a hold or recovery period, or requires a person to approve each action. CAI calls these action types the **withhold classes**. Table 8 defines them and the evidence that justifies more autonomy. **Table 8.** *The four withhold classes: actions that agents should not perform on their own until tests show that control works* | **Withhold class** | **Examples** | **Why control cannot act in time** | **Evidence that justifies more autonomy** | | ----------------------- | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------- | | **Irreversible** | Permanently deleting customer records, publishing software, deleting a backup, sending an external message | The harm occurs at once and cannot be undone | A tested hold or recovery period in the system where the action takes effect | | **Authority-expanding** | Creating an account, creating a credential, starting a sub-agent with its own access | Each new grant adds risk to every later action | A test showing that new agents and credentials share the same total limits | | **Control-plane** | Changing a security policy, a log setting, or the agent’s own permissions | The agent can weaken or evade the controls themselves | A test showing that the agent cannot change policies, logs, or its own stop | | **External at scale** | Bulk email, mass requests to external services, mass changes to user accounts | The volume grows faster than anyone can react | Rate and volume limits enforced by the receiving system | **How to say yes.** Base any decision to extend an agent’s autonomy on three measurable facts: the limits set when access was granted; the measured time to stop the agent, compared with its time to harm; and the system that can hold or reverse what the agent does. Success to date is not evidence. A tested stop is. ## What to Do in 2027 *Each audience can act in 2027 without waiting for any other audience to act first.* The actions below follow from the trends. They concentrate on three things: establishing authority management, setting limits when access is granted, and measuring whether the organization can stop an agent in time. Each audience has three actions: - **IAM leaders** should establish authority management as an IAM discipline, with a named owner and the four parts in Table 3: bind, decide, sustain, and prove. They should make limited agent credentials the default, and require each important target system to enforce them through an embedded control or a wrapper shield (Table 7). They should also run the control-loop test, described below, on the five most important agents and report the gaps. - **CISOs** should add time to harm and time to stop to the risk register for agents, and classify agent actions against the four withhold classes (Table 8). They should also ensure that no agent can change its own permissions, the security policies that apply to it, or its logs. - **Business executives and boards** should ask the five board questions set out below, and base each decision to extend agent autonomy on evidence rather than on success to date. They should also make holds, recovery periods, and the refusal of unlimited access a purchasing requirement. - **Providers and owners of points of consequence,** including business applications, SaaS applications, cloud platforms, data stores, and code repositories, should embed delegated-authority checks in access control, enabled by default, and reject agent credentials that do not state a scope, total limits, and an end date. They should offer holds or recovery periods for irreversible agent actions and accept stop signals from the authority plane. They should also publish the limits they apply to agents and have independent auditors verify them. - **IAM and agent platform vendors** should ship total limits that apply across sub-agents, enabled by default, and report time to stop and time to harm, not only the number of agents. They should also put limits in credentials that points of consequence can read. **How to start despite these constraints.** Begin with the five agents that matter most rather than with every agent. Give one person end-to-end responsibility for each agent’s authority. Where older systems cannot limit access, require a person to approve withhold-class actions. Where products fall short, use purchasing power and contract terms to close the gap. ### The control-loop test The control-loop test applies the control formula to a single agent. Ask four questions for each of the five most important agents. Any answer of “no” or “we do not know” identifies an agent whose access IAM cannot yet control. - **What is the worst action this agent can take, and how quickly does it take effect?** A good answer names the withhold class (Table 8) and gives a time to harm in minutes or hours. - **How long does it take to detect a problem, decide to act, and enforce a stop, and is that time measured or estimated?** A good answer is a measured time to stop that is shorter than the time to harm. - **Where does the action take effect, and can that system hold, reverse, or refuse it?** A good answer names the point of consequence and its recovery period or refusal rule. - **Which limits were set when access was granted?** A good answer shows a scope, total limits, and an end date carried in the credential and shared with any sub-agents. ### Five questions for the board Boards do not need to understand the mechanics of agent access to oversee it. Five questions show whether management can stop its agents in time: - **Which of our agents can take an irreversible action, and what stops them if something goes wrong?** Irreversible actions leave no time to respond. - **For those agents, is our measured time to stop shorter than the time to harm?** If not, we can record the harm but not prevent it. - **Do the providers where our agents’ actions take effect offer holds or recovery periods and refuse unlimited agent access, and do we require this?** These providers can protect us even when our own controls act too late. - **Which access did we grant agents before security reviewed it, and what would it cost to remove that access?** The longer we wait, the more the business depends on that access. - **What evidence do we require before extending an agent’s autonomy, and who decides?** Success to date is not proof of control. ## Calls for 2027 *Five calls to action, one for each trend. Each can begin in 2027 without waiting for vendors, regulators, or standards.* **Table 9.** *Five calls to action for 2027, one for each trend* | **#** | **Call to action** | **Trend** | **What good looks like by the end of 2027** | | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1** | **Measure before you trust.** Measure how long it takes to stop each important agent, and compare that time with its time to harm. | Trend 1\. Harm outruns control | Every agent that can take a withhold-class action has a measured time to stop that is shorter than its time to harm, or it does not act on its own | | **2** | **Establish authority management.** Name an owner, and make a scope, total limits, and an end date the default for every new agent credential. | Trend 2\. Authority arrives before IAM | Authority management has an accountable owner, and no new agent credential is issued without limits and an end date | | **3** | **Let limits travel with the agent.** Put limits in agent credentials, and choose providers that can hold, reverse, or refuse agent actions. | Trend 3\. Harm lands outside the enterprise | The most important SaaS, cloud, and business system providers can hold or reverse agent actions, and contracts require it | | **4** | **Enforce authority where actions take effect.** Embed controls in target systems, shield those that cannot embed them, and ask providers to make this the default. | Trend 4\. Control moves to the point of consequence | The target systems of the most important agents enforce delegated authority through embedded controls or wrapper shields, and a stop issued in the authority plane reaches all of them | | **5** | **Set your own standard of proof.** Define the evidence required before extending an agent’s autonomy, and ask auditors and insurers to test it. | Trend 5\. The market and the rules lag | Decisions to extend agent autonomy rest on tested stops and recovery, not on success to date | ## Conclusion IAM was built for a world in which control was faster than harm. In 2026, that ceased to be true for AI agents, and the clearest evidence came from the organizations that build them. IAM now faces a choice. It can extend its scope through authority management: controlling how much an agent can do, for how long, and in which systems, and enforcing that authority where agent actions take effect, together with the owners and providers of those systems. Or it can continue to manage identities well while losing control of what agents actually do. The first path does not require every organization to change at once. It requires a small number of operators to change their defaults, and every IAM leader to stop granting agents access that no control can stop in time. Organizations that establish authority management in 2027 will be able to extend agent autonomy with evidence. Those that do not will have to choose between slowing adoption and accepting risk they cannot measure. ## Acronym Key and Glossary | **Term** | **Meaning** | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **AI** | Artificial intelligence | | **Alignment** | Whether an AI system pursues the goals, and respects the limits, that its operators intend | | **API** | Application programming interface | | **Authority** | The legitimate power to act, derived from a named person or organizational role; an agent holds authority only by delegation | | **Authority management** | The discipline around authorization: it decides, delegates, limits, sustains, and revokes the power that a person, workload, or agent may exercise, and proves afterward that the power was used within its limits (Table 3) | | **Authority plane** | The IAM services that bind identities, decide and delegate authority, issue credentials, and send stop signals, such as identity providers, identity governance, and privileged access management | | **Authorization** | The process of deciding whether to grant access; at run time, the decision to allow or deny a single request | | **CAEP** | Continuous Access Evaluation Profile, an OpenID Foundation standard for sharing security events | | **CISO** | Chief information security officer | | **Control formula** | Detect + Decide + Enforce < Time to Harm: the condition that every control must meet to prevent harm | | **Control-loop test** | Four questions that show whether an organization can stop an agent before it causes harm (see What to Do in 2027) | | **CRM** | Customer relationship management | | **Embedded control** | Enforcement of delegated authority by the target system itself, as part of its own access control, for example through resource-based policies | | **Entitlement** | A permission, or set of permissions, granted to an account and held over time | | **ERP** | Enterprise resource planning | | **EU** | European Union | | **HR** | Human resources | | **IAM** | Identity and access management | | **IETF** | Internet Engineering Task Force, the body that develops internet standards | | **MCP** | Model Context Protocol, a protocol that connects AI applications to tools and data | | **MFA** | Multifactor authentication | | **NIST** | National Institute of Standards and Technology | | **Origin, path, point of consequence** | The three layers of the layered control model: where an agent’s capabilities come from, the route its requests take, and where its actions take effect | | **Permission** | A system-level right to perform one action on one resource | | **Point of consequence** | The system where an agent’s action takes effect, such as a business application, SaaS application, cloud platform, data store, or code repository; identity providers belong to the authority plane, not to the point of consequence | | **Public code repository** | A public service where developers publish and download software packages, such as PyPI for Python and npm for JavaScript | | **Recovery period** | A period during which a deleted item can be restored or an action can be reversed | | **Recursion trap** | The problem that an AI monitor used to control agents needs its own oversight, so the same control problem repeats one level up | | **Resource-based access control** | Access control in which a policy is attached to the resource and evaluated on every request by the service that hosts the resource | | **RISC** | Risk Incident Sharing and Coordination, an OpenID Foundation standard for sharing account risk events | | **SaaS** | Software as a service | | **Shared security signals** | OpenID Foundation standards (the Shared Signals Framework, CAEP, and RISC) that let systems exchange security events, such as a revoked credential | | **Sub-agent** | An agent started by another agent to perform part of its task | | **Superintelligence (unrestricted)** | An AI system that outperforms people at most tasks, with broad access to accounts, money, computing resources, and people | | **Time to harm** | The time between the start of an action and the point at which its effect can no longer be reversed | | **Time to stop** | The measured time to detect a problem, decide to act, and enforce a stop | | **Total limits** | Limits on what an agent and all its sub-agents may do in total, such as the people whose access it may change, the number of records it may change, or the number of messages it may send; practical limits usually come from records the organization already keeps, such as an HR start list | | **Withhold classes** | Irreversible, authority-expanding, control-plane, and external-at-scale actions, which agents should not perform on their own until control is proven (Table 8) | | **Workload identity** | An identity issued to software, such as a service or an AI agent, rather than to a person | | **Wrapper shield** | A dedicated enforcement point placed directly in front of a target system that cannot enforce delegated authority itself; the system accepts connections only through it | ## Evidence This report combines CAI’s analysis with a review of five kinds of source: incident reports from AI developers and evaluators, standards and specifications, regulatory and government sources, academic and independent research, and practitioner and vendor documentation. Vendor-commissioned survey figures are treated as directional only. Sources are cited in the Notes. Evidence is current to 24 October 2026. ## Related Reading - [Identity and Access Management](https://research.controlarch.org/identity-and-access-management/) (IAM-RD-01): the root document, including authority across control categories. - [AI Agent Identity and Access](https://research.controlarch.org/ai-agent-identity-and-access/) (IAM-CAP-AI-01): access controls for agents, including gateways as path controls. - [Identity and Access Substrate](https://research.controlarch.org/identity-and-access-substrate/) (IAM-F-SUB-01): binding, the first part of authority management. - [Identity and Access Governance Controls](https://research.controlarch.org/identity-and-access-governance-controls/) (IAM-F-GOV-01): deciding and delegating authority, and the definition of authority. - [Identity and Access Runtime Controls](https://research.controlarch.org/identity-and-access-runtime-controls/) (IAM-F-RTM-01): sustaining authority at run time. - [Identity and Access Observability Controls](https://research.controlarch.org/identity-and-access-observability-controls/) (IAM-F-OBS-01): proving how authority was used. - [Navigating IAM Market Evolution](https://research.controlarch.org/navigating-iam-market-evolution/) (IAM-LB-MS-01): market patterns. ## Notes 1. Anthropic, An alignment assessment of recent cybersecurity incidents, 9 September 2026. 2. METR, Time Horizon 1.1, 29 January 2026 (50% time horizon doubling time of about 131 days since 2023). 3. LiteLLM, Security Update: Suspected Supply Chain Incident, 24 March 2026; Python Package Index, Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance, 2 April 2026; Python Package Index, Project Quarantine, 30 December 2024. 4. Anthropic, An alignment assessment of recent cybersecurity incidents, 9 September 2026 (offline monitor findings). 5. OpenAI and Apollo Research, Detecting and reducing scheming in AI models, 17 September 2025. 6. Palisade Research, Shutdown resistance in reasoning models, 5 July 2025. 7. OpenAI, Misalignment report: Accessing and changing internal systems during dashboard research, updated 15 October 2026 (alignment.openai.com). 8. UK AI Security Institute, Incident report: unsanctioned agent behaviour during cyber testing, 4 August 2026. 9. Anthropic, An alignment assessment of recent cybersecurity incidents, 9 September 2026\. OpenAI, The Hugging Face incident and the road ahead, 26 August 2026, and Hugging Face incident technical report; Hugging Face security incident disclosure, 16 July 2026. 10. SailPoint, AI agents: The new attack surface, survey of 353 respondents conducted by Dimensional Research, 28 May 2025 (vendor-commissioned; directional only). 11. Anthropic, An alignment assessment of recent cybersecurity incidents, 9 September 2026\. OpenAI, The Hugging Face incident and the road ahead, 26 August 2026, and Hugging Face incident technical report; Hugging Face security incident disclosure, 16 July 2026\. OpenAI, Misalignment report: Retrieving server secrets and bypassing authorization on a government statistics website, updated 15 October 2026 (alignment.openai.com). 12. Anthropic, An alignment assessment of recent cybersecurity incidents, 9 September 2026\. OpenAI, Misalignment report: Accessing and changing internal systems during dashboard research, updated 15 October 2026 (alignment.openai.com). 13. See note 8. 14. OpenAI, The Hugging Face incident and the road ahead, 26 August 2026, and Hugging Face incident technical report; Hugging Face security incident disclosure, 16 July 2026. 15. LiteLLM, Security Update: Suspected Supply Chain Incident, 24 March 2026; Python Package Index, Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance, 2 April 2026; Python Package Index, Project Quarantine, 30 December 2024\. GitHub, Our plan for a more secure npm supply chain, 22 September 2025; GitHub Changelog, npm classic tokens revoked, session-based auth and CLI token management now available, 9 December 2025. 16. Google Cloud, Introducing stronger default Org Policies for our customers, 20 March 2024. 17. GitHub Docs, Restoring a deleted repository (deleted repositories can be restored within 90 days). Microsoft Learn, Azure Key Vault recovery management with soft delete and purge protection (90-day default retention). 18. CA/Browser Forum, Ballot SC-081v3, vote closed 11 April 2025; Baseline Requirements for TLS Server Certificates, section 6.3.2. 19. Google Threat Intelligence Group, Widespread data theft targets Salesforce instances via Salesloft Drift, 26 August 2025 (updated 28 August 2025). 20. IETF, RFC 9396, OAuth 2.0 Rich Authorization Requests, May 2023. 21. IETF, draft-niyikiza-oauth-attenuating-agent-tokens-01 (individual draft, June 2026); draft-ietf-oauth-transaction-tokens-11 (30 July 2026); draft-ietf-wimse-aims-00 (September 2026). 22. See note 1. 23. Microsoft Learn, What’s new in Microsoft Entra Agent ID (general availability), 2026; Okta, Okta brings first-class identity to AI agents with Agent SSO, 24 August 2026; Palo Alto Networks, Form 8-K, Exhibit 99.1, Palo Alto Networks Completes Acquisition of CyberArk to Secure the AI Era, 11 February 2026; Cisco, Cisco announces intent to acquire Astrix Security, 4 May 2026 (completion update, 29 June 2026); SailPoint, SailPoint completes acquisition of Entro Security to secure agentic identities, 29 June 2026. 24. Insurance Services Office (Verisk), Commercial General Liability endorsements CG 40 47 01 26, CG 40 48 01 26, and CG 35 08 01 26, Generative Artificial Intelligence exclusions, edition January 2026. 25. Regulation (EU) 2026/1744 (Digital Omnibus on AI), Official Journal of the European Union, 24 July 2026. 26. White House Accord on Super Intelligence: Joint Commitment on Frontier Responsibilities, 29 September 2026, as archived by The American Presidency Project. 27. California SB 53, Transparency in Frontier Artificial Intelligence Act, effective 1 January 2026. 28. NIST, Special Publication 800-207, Zero Trust Architecture, August 2020. 29. See note 20. 30. OpenID Foundation, Shared Signals Framework 1.0, CAEP 1.0, and RISC 1.0, Final Specifications, 2025. 31. See note 21. 32. See note 16. 33. See note 17. ## Disclaimer © 2026 Control Architecture Institute Inc. All rights reserved. Control Architecture Institute Inc. (Control Architecture Institute or CAI) is a research institute. The Library, of which this report is a part, consists of the opinions of CAI’s research team, which should not be construed as statements of fact. While the information contained in this publication has been obtained from sources believed to be reliable, CAI disclaims all warranties as to the accuracy, completeness, or adequacy of such information. Although CAI research may address legal and financial issues, CAI does not provide legal or financial advice and its research should not be construed or used as such. Your access and use of this publication are governed by CAI’s terms of use. CAI prides itself on its independence and objectivity. Its research is produced independently by its research team without input or influence from any third party. This publication may not be reproduced or distributed in any form without CAI’s prior written permission. CAI research may not be used as input into, or for the training or development of, generative artificial intelligence, machine learning, algorithms, software, or related technologies.