AI Agent Permissions in 2026: What ARTEX Proves About Handing Over Your Keys

The short version: in the same two weeks, Microsoft attributed a supply-chain breach to an open-source agentic penetration-testing framework that ran at machine speed — 2,900 failed logins a minute, under 3 hours from targeting to privileged access, more than 2,250 tenants attempted — while the web went the other way: Yelp, Delta, JPMorgan and Charles Schwab are now blocking AI agents outright. Both stories are the same missing piece. The question is no longer whether your agent is smart enough; it is what you handed it and where the enforcement lives. Everything below is about permissions, and the answer is not "trust the model."

Two directions, one problem

Start with the machine-speed side, because the numbers are the argument. Microsoft's Threat Intelligence write-up on Storm-0940 describes an actor that used ARTEX — an open-source agentic pentesting framework — to automate attacks against hundreds of organizations from September 2026 across aerospace, defence, automotive, energy, financial services, government, legal, manufacturing, semiconductor and software targets. In several cases the time from picking a target to privileged cloud access was under three hours.

The parkable detail is what the automation actually did. Between October 10 and 14, one address in the actor's infrastructure sprayed passwords across 327 accounts in eight organizations. Microsoft's telemetry recorded 151,000+ failed logon events, peaking at 2,900 failures per minute on October 11 and more than 111,000 in a single day; 48 accounts took over 1,000 failures each, and lockout responses were nearly 98% of the activity. Notably, that phase produced no successful authentication. Then, after the ConnectWise cloud-backup compromise, the agents authenticated into customer environments using stolen application credentials — the trust those apps already had — and reached more than 2,250 tenants. In some environments they went past sign-in into Microsoft Graph and directory operations: reconnaissance, application credential changes to establish persistence, and changes to identities, groups and privileged roles.

Now the other side. The Verge reported on Oct 17 that services are closing their doors to agents: Yelp only allows agents that pay for its data licensing programme, Delta won't let them book tickets, JPMorgan Chase and Charles Schwab confirmed they block agent access to accounts on security grounds, and users say Cars.com and Amtrak quietly stopped working. Amazon had already banned and sued over Perplexity's agentic shopping.

Put those together and the shape of the problem is obvious. An agent is a program holding your credentials, acting with your authority, at a speed you cannot supervise. Sites are blocking them because they can't tell agent from attacker from customer. Both are authorisation failures, and you can only fix your half.

The sentence in Microsoft's post that should change your threat model

Buried in the mitigation guidance is the finding that matters for anyone running agents against SaaS:

"The application credential modification made by Storm-0940's associated agents in the targeted victims' environments can lead to persistence through other identities, credentials, and cloud services. These changes can remain active as a backdoor even after the original compromised application is mediated."

— Microsoft Threat Intelligence, Oct 21, 2026

They also state the general case plainly: "a compromised third-party application with high privileges could provide access beyond its originally intended purpose." That is a description of your agent's OAuth grant if it has one. If your agent connects to Slack, GitHub, a CRM or a mail account with a standing token, you are running a high-privilege third-party application and calling it a feature. And Microsoft's remediation starts with an admission of how normal this is: inventory the affected application IDs, and search by application ID rather than display name, because most tenants cannot answer "which apps can read my mail" from memory.

Where enforcement actually has to live

Three layers, and the tools available at each today. The important pattern across them is that none of them enforces anything inside the model.

The design principle is worth stealing even if you build it yourself. One of Alter's founders (kdodhia on HN) answered a question about prompt-injected agents with the assumption most teams haven't made yet:

"We assume you can't reliably stop the model from being prompt injected. So nothing is enforced at the model layer. Enforcement happens at the proxy, which sits between the agent and the downstream API and is the only thing holding the credential."

— kdodhia, HN

He also confirms what keeps it deterministic: "nothing at request time is a model call" — rules are evaluated against the actual request, its method and path, and the provider operation it maps to (HN). If your authorisation decision requires an LLM to decide whether the action is allowed, you have moved the vulnerability, not closed it.

The test almost nobody runs

The most useful comment in the whole fortnight was a developer reporting a measurement on a multi-user agent before it knew which user it was serving:

"Measured on an agent I run, before it knew whose request it was serving: 7 of 10 checks failed. Acting for an account manager, another manager's customer record came back in full. Acting for first-line support, who may not send email, it sent one. What fixed it was putting the ownership rule at the one door every call goes through."

— heyvaldemar, HN

Seven of ten privilege checks wrong, on a real system, from memory leakage rather than malice — the agent simply had the other user's data in context. The same thread flags the adjacent failure: higher-privilege context bleeding into a lower-privilege session (souvik1997, HN). If you run a multi-user agent, that is your test: ask agent A, acting for user A, for user B's record — then ask it for something only a manager can do. Ten checks, one afternoon, and the failure rate is usually not zero.

The counter-argument, which is half right

Not everyone wants kernel-level pedantry, and they have a point:

"Taking default telemetry is insane. That aside, the level of control is cool, almost too pedantic. It likely is only particularly useful for very nuanced enterprise requirements... Most companies can be much more coarse with their permissions."

— dangoodmanUT, HN

Match the granularity to the blast radius. A local coding agent on your laptop needs a sandbox and an allowlist, not a policy engine. An agent holding a CRM token for 40 salespeople, or a mail token, needs per-call decisions. The one rule that survives both cases: the agent should not hold the credential — and this is not theoretical. The week before the ConnectWise news, attackers hit the AI coding tool OpenCode and ran up charges on users' AI accounts (TechCrunch, Oct 19; the Hacker News thread on it drew 974 points). The team's own notice in that thread describes the failure mode better than any checklist:

"We identified unauthorized access to a legacy system that we were in the process of decommissioning. Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed. Please revoke and replace those keys."

— OpenCode team, HN

Keys saved in a workspace are keys an attacker can spend. That is what a commenter in the Alter thread meant by running your own gateway:

"Companies doing this make themselves a target and then get hacked like OpenCode. Customer accounts get drained or bills run up."

— verdverm, HN

If you run an agent against real systems, do these six things

1. Inventory the grants before you configure anything. List every OAuth app and API key your agents can reach, and — if you're on Microsoft 365 — follow Microsoft's instruction to search by application ID rather than display name, including integrations you no longer use. Record the service-principal object ID per tenant.
2. Stop letting the agent hold the secret. Move keys into a vault and inject them at egress, only for approved endpoints. Vaulted keys that nobody — including the developer — can read back is the pattern both Alter and OpenShell implement.
3. Default to deny, per call, and get as fine as the provider allows. When the upstream API only offers one giant scope, that is precisely when a proxy layer earns its price.
4. Enforce outside the model, always. Assume prompt injection succeeds. Reason about the actual request, not the model's summary of its intent.
5. Put a named human in front of irreversible calls — payments, deletions, permission changes — and make retries idempotent so approval can't double-execute.
6. Run the cross-user leak test quarterly. Ten probes: can agent A retrieve user B's data, and can a non-manager's agent perform a manager action? Then check your sign-in and audit logs for unexpected application credential or role changes.

Who does the security review now? → When agent incidents get reported →

Method: primary sources read on 2026-10-23 — Microsoft Threat Intelligence's Storm-0940/ARTEX post, NVIDIA's OpenShell README and repository, Alter's product and pricing pages, and The Verge's Oct 17 report on sites blocking agents. Aggregated: four Hacker News threads (1,538 points, 553 comments) — the OpenShell launch, the Alter (YC S25) launch thread including founder replies, the agent-blocking discussion, and the OpenCode credential-leak thread. Quotes are verbatim with permalinks; press facts (OpenCode, Oct 19; ConnectWise advisory, Oct 16) are attributed by outlet and date rather than linked. We don't take payments from vendors.