Agentic shadow AI doesn't care what you call super intelligence

On September 29, 2026, the White House signed Executive Order 14434, "Inaugurating the Era of Super Intelligence." The order tells federal agencies to use "Super Intelligence," or "SI," in official communications instead of "AI." It tries to change a term. It defines no new technology and creates no new risk category, so there is no Shadow Super Intelligence to plan for.

The risk we already have is agentic shadow AI: autonomous agents running without sanction or supervision. AI systems that operate inside your organization without a human approving each action, holding their own credentials instead of borrowing a person's login. That kind of agent doesn't care what the federal government calls it. The agent still has the OAuth token, and the token still works whether the paperwork says AI or Super Intelligence.

Key takeaways: your agents never got the memo that it's SI now

Executive Order 14434 (September 29, 2026) tells US federal agencies to write "Super Intelligence" instead of "AI" in official documents. It defines no new technology, sets no penalty, and places no obligations on private companies.
The risk to plan for is agentic shadow AI: autonomous agents that nobody inventoried, running on their own API keys, OAuth tokens, or service accounts.
An agent acts without a human login event. Its traffic looks like routine automation, so detection rules built for stolen user passwords miss it.
JumpCloud found that 83% of organizations manage more non-human identities than human users, while only 21% govern access for those identities.
Agents reach production through seven routes that bypass approval: developer tooling, pilots that never end, orphaned agents, vendor feature flags, low-code builders, personal agents, and third-party teams.
A forgotten credential causes the damage. Klue's token, issued in 2022 for a limited pilot, was still valid when attackers used it in June 2026.
The 5-step agent credential checklist starts with an inventory of which agents hold which credentials. You cannot scope, rotate, or revoke a credential you have not found.

What the "Super Intelligence" order actually changes (it doesn't)

Executive Order 14434 is a terminology directive for the US executive branch. agencies to write "Super Intelligence" ("SI") instead of "AI" in official non-statutory documents. It places no obligations on private companies and carries no penalty. It also starts a 60-day process that could end in a new statutory definition.

President Trump signed the order on September 29, 2026. It was published in the Federal Register on October 2 (91 Fed. Reg. 63129). The operative provisions:

Section 1 sets the policy: to the maximum extent permitted by law, the executive branch uses "SI" in place of "AI" and "will not acknowledge" the old terms in any applicable setting.
Section 2(a) applies the rule to official correspondence, public communications, websites, reports, policy documents, and other non-statutory documents.
Section 2(b) states that nothing in that section requires altering existing regulations, Presidential actions, contracts, grants, or other historical documents.
Section 3(a) defines "SI" by reference to the existing statutory definition of AI in 15 U.S.C. § 9401(3). The definition holds until superseded by Presidential action or an Act of Congress.
Section 3(b) gives the White House science advisor 60 days to propose new legislative language, which would need separate congressional action to take effect.
Section 4(c) states that the order creates no enforceable rights.

Strict wording, little legal effect

The order's language is stricter than its effect. Section 1 says the executive branch "will not acknowledge" the term AI in any applicable setting, yet the order itself uses "artificial intelligence" and anchors its definition of SI to 15 U.S.C. § 9401(3). Every obligation applies only "to the maximum extent permitted by law" and only to non-statutory documents, so statutes, regulations, contracts, and grants keep saying AI.

Screenshot of a post by Donald J. Trump saying the White House considers anyone who uses “Artificial Intelligence” instead of “Super Intelligence” the enemy. — The White House’s position on what to call AI, as posted by Donald J. Trump

Section 3(a) makes SI mean exactly what AI means today, and section 4(c) creates no enforceable rights. Lawyers at Arnold & Porter note that the order has no penalty or enforcement provision. The President's October 8 post calling anyone who says "Artificial Intelligence" "THE ENEMY" went further than the order, and the order names no consequences for it. Agencies change their vocabulary. The technology and its regulation stay as they were.

That is the entire scope of the order: a communications exercise and vocabulary rule for one government's own paperwork. The agents already connected to production systems, holding the credentials they already hold, do not care which word appears in that paperwork.

What agentic shadow AI actually is

Agentic shadow AI is the unsanctioned or unsupervised use of autonomous agents inside an organization. These agents plan and chain actions on their own, hold their own credentials, and run without a human approving each step. Unlike shadow IT or general shadow AI, they need nobody at a keyboard to act.

Traditional shadow IT is an employee adopting a tool, such as a file-sync app or a project tracker, without going through procurement. General shadow AI, the kind most governance posts cover, is an employee pasting data into a public chatbot. Both involve a person making a choice in the moment, and both eventually surface somewhere: an expense report, a SaaS usage log, a browser history entry.

Agentic shadow AI works differently. An agent leaves a trace only once. Someone connects a Slack bot, a sales-tooling integration, or a script that watches a code repository, and from then on the agent acts on its own schedule. It authenticates with its own API key, OAuth token, or service account. A token issued once keeps working until someone revokes it, so no later human decision exists for anyone to notice or flag.

Criterion	Shadow IT	Shadow AI	Agentic shadow AI
Who acts	An employee, without IT approval	An employee, in a single session	An autonomous agent, often set up once and then forgotten
What it can do	Run one unsanctioned tool	Process or expose one prompt's worth of data	Chain actions across systems with no approval per step
Credential it uses	A personal or shared login	The employee's own session	Its own API key, OAuth token, or service account
Why it's hard to see	Shows up in expense reports or logs eventually	Shows up in browser or SaaS usage logs	Leaves no human login event; the traffic looks like routine automation

Why MCP widens the problem

Agents built on the Model Context Protocol (MCP) reach tools and data sources through whatever credential the integration was configured with. They inherit that credential's full access. The access is frequently broader than the one task the agent was built for, and nobody revisits the scope once the integration works.

Some vendors call these systems "shadow agents." This article uses "agentic shadow AI" throughout. Both labels describe the same problem: autonomous agents that nobody inventoried, holding credentials that nobody is watching.

Why agentic shadow AI is worse than shadow IT

Agentic shadow AI is harder to contain than shadow IT because agents get connected to real systems faster than organizations assign owners, scope credentials, or inventory them. Shadow IT needs a person to keep using the tool. An AI agent keeps working after its creator moves on.

The gap shows up in three published figures.

JumpCloud found that 83% of organizations manage more non-human identities (NHIs), meaning service accounts, API keys, and agent credentials, than human users. Only 21% have access governance for those identities.
Cyberhaven Labs recorded a 509% year-over-year increase in enterprise use of endpoint-based AI agents between February 2025 and February 2026. Coding assistants alone grew 357%.
Gartner predicted in August 2025 that 40% of enterprise applications would include task-specific AI agents by the end of 2026, up from less than 5% in 2025.

Adoption is accelerating, and governance covers a small share of the identities involved. Most teams cannot answer "what can this credential access?" on demand. Without that answer, nobody can scope, rotate, or revoke the credential.

What a gap costs

The cost of a breach gives the problem a dollar value. IBM's Cost of a Data Breach Report 2026 puts the global average breach cost at $4.99 million, a record and a 12% increase over the prior year. IBM does not attribute that figure to agents, so read it as the price of the failure mode, not as the price of agentic shadow AI.

An unowned credential is the same failure whether a person or an agent holds it. The difference is detection. A person who misuses access leaves a login event. An agent with a valid token produces traffic that looks like routine automation.

Put plainly: organizations are building up non-human identities (NHIs) and connecting agents to production systems well ahead of building the ownership records, scoping discipline, and monitoring.

How AI agent sprawl happens in organizations

Seven routes lead to agent sprawl in governed organizations: developer tooling, pilots that never end, orphaned agents, vendor feature flags, low-code builders, personal agents, and third-party teams. Each one ends with an agent holding a credential that no central owner has recorded.

Developer tooling. Coding assistants and locally run MCP servers work with the repository tokens and cloud keys already sitting on a developer's machine. They run on the endpoint, so no SaaS admin console lists them.
A pilot that never ended. A team wires up an agent to fix one irritating task. It saves hours, colleagues come to depend on it, and nobody schedules the decision to approve it or shut it down. The key it was created with keeps its original scope.
Orphaned agents. The person who built an agent changes roles or leaves, and the agent carries on. Disabling their directory account does not necessarily revoke the OAuth grants and API keys they created. Check how each of your systems behaves.
A feature flag in a trusted tool. A vendor ships an agent in a routine update and turns it on for every tenant. The agent reaches data through connections the product already holds. The security review on file describes the product as it was a year ago.
Low-code agent builders. Business users assemble agents in workflow platforms the company already licenses. Every connection the agent makes is created under the builder's identity, so the platform's admin sees apps, not the credentials behind them.
A personal agent. An employee links an assistant to their inbox, calendar, or code repository and lets it act with their own permissions. Those permissions were granted for the person's whole job, so the agent has far more reach than its one task requires.
Third-party and acquired teams. An agency, a consultant, or a newly acquired company brings agents that already run on their own credentials. Those credentials never pass through your onboarding.

Two credential breaches, ten months apart

Two named incidents, a year apart, show what an ungoverned machine credential actually costs. In both cases, a forgotten OAuth token or access key sat connected to an AI-adjacent integration with nobody watching it, until an attacker found it first.

Salesloft Drift, August 2025

The threat actor UNC6395, tracked by Google's Threat Intelligence Group, exploited Salesloft's Drift AI chatbot integration with Salesforce to harvest OAuth access and refresh tokens. Drift connects to a customer's Salesforce instance to automate sales conversations, and that connection runs on a standing OAuth grant rather than a one-time login.

Once UNC6395 had working tokens, the attack moved at machine speed: the group used them to query Salesforce objects directly and pull whatever credentials and case data those tokens could reach.

From there, the attacker pulled AWS access keys, Snowflake tokens, stored passwords, and support-case data out of connected environments. The goal throughout was data exfiltration through a trusted, already-authorized channel rather than a break-in through the front door. A Google threat analyst told Cybersecurity Dive that over 700 organizations could potentially have been affected. Cloudflare, Zscaler, and Palo Alto Networks confirmed they were among them.

Klue, June 2026

On June 11, 2026, an attacker used a GitHub personal access token to push unauthorized code into Klue's integration service. The code collected the OAuth access and refresh tokens that customers had granted to the Klue Battlecards app. With those tokens, the attacker queried customers' Salesforce tenants and exported contacts, opportunities, quotes, and sales notes.

According to Klue's CrowdStrike investigation summary, as quoted by the NHI Management Group, the token had been "previously compromised." Huntress describes it as long-disused but still active. Klue told TechCrunch it was issued to a third party in 2022 for a limited pilot. Salesforce alerted Klue on June 12, and Klue revoked the tokens and rotated credentials that morning. The extortion group Icarus claimed the attack.

Klue has not published a victim count. At least eleven companies had confirmed impact by June 25, among them Huntress, Recorded Future, Tanium, Jamf, Gong, HackerOne, Snyk, OneTrust, Insurity, and Sprout Social. A second extortion group claimed 195 customers, and that claim is unverified.

The entry points differ. At Klue it was a stale source-control token. The Drift sources describe the use of stolen OAuth tokens, not how they were obtained. The shared exposure is a non-human credential with standing access to customer data, held by a vendor and usable without a login event. Traffic from a valid token looks like the integration itself.

Klue's token stayed valid for about four years after a pilot ended. Drift's tokens stayed valid until someone revoked them.

Risks of agentic shadow AI

Agentic shadow AI create five risks: exposed long-lived credentials, activity that looks like normal traffic, excessive agency, credential chaining between agents, and compliance gaps. They share one cause. The agent acts on its own with a credential that nobody inventoried, scoped, or reviewed.

Long-lived credentials that outlive their purpose

An agent keeps working as long as its key or token is valid, and nothing in the agent forces a review. Pilot credentials are rarely rotated and often keep the broad scope they had during testing.

Klue is the clearest case. According to the company's own account, a token issued in 2022 for a limited pilot was still valid when attackers used it in June 2026. Nobody had decided to keep it. Nobody had decided to retire it either.

Activity that looks like normal traffic

An agent authenticates with its own API key or OAuth token, so no human login event exists to flag. Its requests come from a known integration, at regular intervals, through approved APIs. Detection rules built for stolen user passwords have nothing to match.

Data loss through an agent therefore tends to surface late. The first signal is often a vendor notice or an unusual invoice, not an alert in your SIEM.

Excessive agency

Agents that reach tools and data through MCP inherit the permissions of the service account behind them. Those permissions are usually granted for a broad range of tasks, not for the one the agent performs. The gap is the attack surface.

OWASP lists this pattern as Excessive Agency (LLM06:2025) in its Top 10 for LLM applications. An agent that reads untrusted content, such as an email or a web page, can be steered into using access it should never have held. Narrow scopes limit what a successful injection can reach.

Credential chaining between agents

When one agent calls another, the downstream agent often receives the upstream credential or a token derived from it. A compromise in the weakest agent then opens everything the strongest one can touch. Unregistered agents make this worse, because nobody has mapped which agent trusts which.

Compliance and audit gaps

An uninventoried agent processes data outside your records and controls. GDPR Article 32 requires "appropriate technical and organisational measures" to secure personal data, and a credential nobody owns is hard to defend as one. NIS2 Article 21(2)(i) lists access control policies and asset management among the required risk measures.

Governing agentic shadow AI: the 5-step agent credential checklist

The 5-step agent credential checklist governs agentic shadow AI through the credentials agents run on. Find every agent and its secrets, issue each one a separate scoped identity, name a business and a technical owner, set runtime limits, then log, test, and revoke on a schedule.

Step 1. Discover agents through the credentials they hold

Agents are easy to miss, but their credentials leave records in the systems they touch. Search these places first:

OAuth grants and connected apps in each SaaS admin console
service accounts and service principals in your identity provider and cloud accounts
secret stores, repository variables, and CI/CD settings
API gateway consumer lists
endpoints: installed assistants, browser extensions, and Model Context Protocol (MCP) configuration files

For each agent, record what it can reach, which tools or APIs it calls, what data it reads or writes, and who switched it on. The first pass will be incomplete. Repeat it on a schedule, because new agents appear faster than quarterly reviews.

Step 2. Issue each agent its own identity and scope it

An agent should never run behind a shared account or an employee's personal login. Create one identity per agent, tied to its workload. Then remove the broad permissions the agent picked up during testing, so that access matches the one job it does in production.

The same rule covers agents that call other agents. Each agent authenticates on its own, and one agent's credential is never passed on to another.

In Passwork, a service account is a non-interactive account built for automation. One service account can hold several scoped API tokens, so each agent or pipeline gets its own. Vault policies set who administers each vault type, so a vault for agent credentials has corporate administrators from creation. Rotating a credential does not break the pipelines that depend on the account.

Test scoped service-account tokens and vault policies on your own agent credentials. Try Passwork free in your infrastructure.

Step 3. Name a business owner and a technical owner

Each credential needs two people. The business owner accepts responsibility for what the agent is for and what risk is tolerable. The technical owner handles runtime access, logging, and maintenance. Without both, nobody can say whether a credential should still exist.

Klue shows the cost of an empty owner field. According to the company's own account, a token issued in 2022 for a limited pilot was still valid when attackers used it in June 2026. Store the owners, the purpose, and a review date next to the credential. When an owner changes role or leaves, reassign the credential in the same ticket.

Step 4. Set runtime limits before the agent goes live

Write down what the agent may do and what it may never do, and match the depth of review to its autonomy. An agent that only reads a calendar needs a short checklist. An agent that moves money or writes to external systems needs a formal risk review and a sign-off.

Once the agent runs, enforce limits outside its own reasoning layer:

restrict which tools it can call, and validate what goes in and out of each call
block secrets and personal data from leaving through uploads or the clipboard
require human approval for payments, permission changes, and writes to external APIs

Banning every unapproved tool pushes the work out of sight. Offer a sanctioned route that is quicker than the workaround, such as an internal agent platform with these limits already built in.

Step 5. Log, test, and retire

Send agent activity to your SIEM. In Passwork, the Activity log records who read or changed a credential and exports to Syslog or a SIEM. Alert on a token used from a new source or at an unusual volume.

Two drills show whether the controls work:

Trace test: pick one automated action and follow it back to the human who authorized it and the data it used.
Revocation drill: measure how long it takes to cut one agent's access across every system it touches.

Review each agent on its review date. Look for permissions that grew since launch, rotate its credentials, and decommission agents that no longer have a purpose. Google's Threat Intelligence Group gave customers the same advice after the Drift breach: review connected integrations, then revoke and rotate their credentials.

Conclusion

The label changed on September 29, 2026. The underlying risk did not. Agentic shadow AI, an autonomous agent holding a live, unrotated credential that nobody owns, was exactly as dangerous the day before Executive Order 14434 as the day after. Salesloft Drift and Klue, a year apart, already proved that twice over.

Start this week with the first step on the checklist above: a full inventory of which agents hold which credentials. Nothing else on the list works until that inventory exists, because you cannot scope or rotate what you have not found. It is also the one step every security team can start today, without waiting on budget, a new platform, or a policy rewrite triggered by a federal order that has nothing to do with the credentials sitting in your environment right now.

Credential hygiene for AI agents starts the same way it does for employees: know what access exists, who owns it, and when it was last rotated. Try Passwork free.

Frequently asked questions

What is Super Intelligence?

"Super Intelligence" is President Donald Trump's 2026 rebranding of artificial intelligence. He has ordered US agencies to use the term and said in October that anyone who still says "artificial intelligence" is an "enemy" of the White House. It is a label change, not a new technology.

What are the four types of agentic AI?

Reactive agents respond to triggers without planning ahead. Deliberative agents plan multi-step actions toward a goal. Task-specific agents are scoped to one job, such as a coding assistant. Multi-agent systems coordinate several agents that hand off work to each other. Governance needs differ by type, but credential exposure is a risk across all four.

Is agentic AI actually AI, or just automation?

Agentic AI differs from rule-based automation because it plans and chains actions on its own, adapting its next step to what the previous one returned, rather than following a fixed script. A traditional automation runs the same sequence every time. An agent can decide which sequence to run, which is also what makes it harder to audit in advance.

How is agentic shadow AI different from shadow IT?

Shadow IT and general shadow AI both involve a person making an unsanctioned choice in a single moment, such as installing a tool or pasting data into a chatbot. Agentic shadow AI involves an agent that keeps acting on its own schedule, using its own credential, with no further human decision for anyone to notice or flag.

What is Super Intelligence?

Superintelligence is a hypothetical AI system that outperforms the best human minds across nearly every cognitive task, including scientific reasoning, planning, and problem solving. It does not exist today. Current AI agents are narrow tools, and the agent sprawl risks in this article come from their credentials, not from superintelligence.

Can existing DLP or CASB tools detect agentic shadow AI?

Not reliably. Legacy data-loss-prevention and CASB tools are built to flag a browser session or an unsanctioned app, not agent-to-agent calls, MCP server connections, or OAuth-token-level activity between systems. An agent's actions can look like routine automated traffic even when its credential has far more access than anyone intended.

Agentic shadow AI doesn't care what you call super intelligence

Key takeaways: your agents never got the memo that it's SI now