This week’s Cloud Security Newsletter topic: Securing AI Agents at Scale: Paved Roads as APIs, Preventative Controls and an Agent Platform (continue reading)

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI Security Podcast every week.

Welcome to this week’s Cloud Security Newsletter!

A three-zero-day chain in Ivanti Connect Secure gave attackers root on fully patched VPN appliances this week, and SAP, Docker, npm and Vercel each disclosed a flaw in how a credential or a boundary was checked. Eight stories follow, each with a concrete action.

On the AI Security Podcast, Ashish Rajan spoke with Prahathess Rengasamy, a security engineer at xAI who previously worked at Block and Apple, about what happens to security when almost anyone in a company can ship software with agents. Rengasamy says up front that his opinions are his own and do not represent xAI. His answer: keep every preventative control, hand agents your paved roads as an API, and build a platform for them the way the industry did for Kubernetes. [Listen to the episode]

Each story includes why it matters and what to do next — no vendor fluff.

Primary source: SecurityWeek (Eduard Kovacs)
Reporting: The Hacker News

What Happened

Volexity found an actor it tracks as UTA0576 chaining three Ivanti Connect Secure zero-days to get unauthenticated, root-level code execution on a fully patched appliance, with exploitation starting around October 3. An authentication bypass and an RCE bug (CVE-2026-104935) are fixed in ICS 22.8R2.5, 25.1.1.2, 25.1.3.0 and 25.1.3.1. The privilege escalation flaw has no CVE in the coverage and no patch yet; Ivanti plans to fix it over the coming weeks. The actor stole domain credentials stored on the appliance, pulled limited Active Directory metadata and searched for LAPS passwords and BitLocker recovery keys. Volexity found no backdoor or web shell, and Ivanti says exploitation affects a limited number of customers.

Why It Matters

A fixed build is not a closed ticket while the third flaw is open. The appliance stores domain credentials, and this actor went straight for LAPS passwords and BitLocker recovery keys, so one VPN foothold becomes a directory-wide exposure for any hybrid estate that terminates remote access there. Volexity also assesses with medium confidence that the group uses LLMs for exploit development and post-exploitation, which shortens the gap between a patch and a working chain.

Action for defenders: Apply the fixed builds today, then rotate domain credentials stored on any ICS appliance exposed since October 3 and review Active Directory logs for LAPS and BitLocker attribute reads. Watch Ivanti's advisory for the third patch.

Primary source: The Record (Suzanne Smalley)

What Happened

AIR, an AI security startup, reported a flaw in Vercel Sandbox's network filtering. An agent inside the sandbox sends a crafted certificate to an approved server, which then makes a request to an attacker-controlled server, so the sandbox never contacts the attacker directly and its traffic looks normal. Vercel told AIR it needs time to work out a patch. AIR has no evidence of exploitation and cannot rule it out. The coverage names no CVE. 

Why It Matters

An allowlist that trusts a host can be turned against that same host, so egress logs show only approved destinations. Anyone running agent-generated or untrusted code behind a domain allowlist should treat the control as weaker than it reads. AIR says the flaw appears to have existed for a long time, so the exposure has no known start date.

Action for defenders:If agents or generated code run in Vercel Sandbox, limit what data those sandboxes can reach before egress and track Vercel's patch status. For other sandbox products, test whether a trusted host can be induced to make onward requests on a sandbox's behalf.

🛠 If you only do one thing this week:  list every agent, bot and CI job that can modify or delete production resources, and write the named human or approval next to each one. Anything with no name beside it is your first candidate for a preventative control such as an SCP, an organization policy or an admission rule. About 45 minutes.

Primary source: The Hacker News (Ravie Lakshmanan)

What Happened
Bloom Security reported to GitHub on June 6 that npm trusted publishing recorded a repository's owner/repository name instead of its permanent numeric ID until the first successful publish. An attacker who reclaims an abandoned or renamed slug can create a repository there, run a workflow that mints an OIDC token carrying that slug, and trade it for an npm publish credential. Bloom found more than 1,500 vulnerable packages with over 10 million combined downloads. GitHub now expires unvalidated trusted-publisher configurations after 48 hours and rejects tokens from issue_comment events. No in-the-wild exploitation is reported.

Why It Matters
Trusted publishing was adopted to take long-lived tokens out of CI, and this flaw shows the replacement credential was only as strong as the identifier it bound to. A renamed GitHub organization or a deleted repository that once published a package is now an ownership question for every team that moved to OIDC publishing.

Action for defenders: List every package you publish with trusted publishing and confirm each configuration has completed a first successful publish, which validates it and exempts it from the 48-hour expiry. Check for renamed or transferred repositories still named in publisher configurations.

Primary source: The Hacker News (Swati Khandelwal)

What Happened

CVE-2026-105445 (CVSS 4.0 score 9.4) let an attacker create a personal access token, convert their account into an organization and name a victim as owner. The token secret stayed the same and the new owner was neither asked to confirm nor notified, so the token then worked against the registry as that victim. Peter Molnar and Krisztian Hozak of mptrdev.com found it. Exposure ran from August 26, 2024 to the September 30, 2026 server-side fix. Docker says it reviewed about 304,000 pushes made with transferred tokens and found no malicious use; the advisory did not report results for pulls or deletions.

Why It Matters

The flaw skipped passwords and 2FA entirely, so token activity looked like the legitimate owner's.

Action for defenders:No customer patch is needed. Pin production pulls to image digests, review Docker Hub audit logs for organization conversions around your namespaces and rotate any personal access tokens you cannot account for.

Primary source: The Hacker News (Swati Khandelwal)

What Happened

CVE-2026-89111 (CVSS 10.0) comes from the SDK building a token-request URL by inserting the tenant subdomain without validating it, so an attacker who controls that value can redirect the request, with the app's OAuth2 client ID and secret, to their own server. SAP classes it as SSRF. Versions below 0.45.2 are affected, including 0.36.1 and 0.36.2, and the 0.36 line has no fixed release. The Hacker News's own testing found 0.53.0 through 0.55.0 skip the check for Destination service calls; 0.55.1 added it on September 18. SAP's advisory reports no attacks and arrived 53 days after the August 21 fix, which the release notes had described as a bug fix.

Why It Matters

The fix shipped as a routine release 53 days before anyone called it a CVSS 10, so teams that track upgrades by security advisory alone ran exposed for that gap. Every app on an affected version holds a client secret that leaves on a single manipulable input.

Action for defenders: Inventory SAP Cloud SDK for Python versions in services that call SAP, move anything on the 0.36 line or below 0.45.2 to 0.45.2 or later (0.55.1 or later if on 0.53 through 0.55) and rotate the OAuth client secrets those services used.

Primary source: Google Chrome Secure Web and Networking Team
Reporting: BleepingComputer (Bill Toulas)

What happened:
Attackers compromised third-party operators of the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) country-code TLDs, changed authoritative DNS records and obtained valid HTTPS certificates for Google domains and other organizations. Certificate Transparency logs later showed more affected organizations, including large global brands. Chrome blocked the certificates through CRLSets and Google worked with the issuing CAs on revocation. Google says its own systems were not compromised. The operators, issuing CAs, attackers and certificate count are not identified.

Why it matters:
Domain-validated issuance treats DNS control as proof of ownership, so a hijacked zone yields certificates that pass every client check. CRLSets protect Chrome users only; every other client depends on CA revocation. Parked and regional ccTLD domains are where nobody is watching.

Action for defenders: Alert on unexpected Certificate Transparency entries across your full domain portfolio, including parked and regional domains, and publish CAA records bound to specific ACME accounts. During an active hijack CAA cannot stop issuance. Afterwards it blocks reissuance from cached validation.

Primary source: Anthropic Frontier Red Team
Reporting: The Hacker News; SecurityWeek

What happened:
Anthropic's post says models of 30B parameters or fewer can already complete many individual replication steps but fail when chaining them end to end. In simplified evaluations GLM-5.2 and stronger models replicated end to end, and the authors estimate small models reach that level by the end of 2026, calling it a rough proxy estimate. A 9B model got inference running on 8 of 9 hardware types tested, and a 26B model ran across 15 real Android TV boxes at 0.39 tokens per second. The end-to-end replication tests ran on emulators, and Anthropic says it does not yet have a full rogue replicator.

Why it matters:
The modeled threat has no datacenter, no API key and no central off switch, so cloud controls such as key revocation and egress blocks do not reach it. Anthropic's proposed defenses sit with ISPs and device makers: flow-data detection of multi-gigabyte model transfers, honeypots and quarantining subscribers. For an enterprise, the near-term relevance is unmanaged IoT on corporate and home-worker networks as compute and a foothold.

Action for defenders: Add large east-west or outbound transfers from IoT VLANs to detection coverage, and confirm unmanaged TV boxes and similar devices are segmented away from networks that reach cloud management planes.

Primary source: SecurityWeek

What happened:
IonQ agreed to buy Elisity in an all-stock deal worth up to $1.3 billion, including up to $150 million in earnout. The share count floats with IonQ's 20-day volume-weighted average price, bounded between $33.07 and $49.61. Elisity, founded in 2019, sells least-privilege policy for users, devices, workloads and AI agents, with more than 100 customer deployments. IonQ expects to close in Q4 2026 and plans to add cryptographic inventory and risk data to Elisity's IdentityGraph to prioritize post-quantum migrations.

Why it matters:
A quantum-computing company is buying microsegmentation and an identity graph to sell post-quantum migration into CISO accounts, which turns cryptographic inventory into an input for segmentation policy.

Action for defenders: If Elisity is in your stack or on a shortlist, ask for roadmap and support commitments under IonQ ownership before renewal, and start a cryptographic inventory either way.

Rengasamy's argument has three layers. At the base sit the controls that have not changed: preventative controls, least-privilege identity and a catalog of where sensitive data lives. Above that, security guidance becomes something an agent can query while it works, through hooks and a security-run MCP service. At the top is a platform built with engineering, which gives a large company one governed path for agents and visibility into the exceptions.

He applies the platform approach first to coding agents, since those change repositories and infrastructure, and measures the risk of any agent by how many of its actions change something.[Listen to the full episode →]

Before diving into our insights, let's clarify some key terms:

This week's issue is sponsored by AI Security Lab

Prahathess Rengasamy describes the old flow as requirements, design documents, a pull request, approvals, tests, staging and promotion to production, and says it held until roughly a year and a half or two years ago. Models then got good at coding, and he now runs several agents at once. A small feature can be in front of millions of users within a week or two, and if people dislike it, it is scrapped after the fact. Rengasamy: "The time between idea to something shipped has compressed A whole lot, and across multiple surfaces."

The second change is who builds. Rengasamy: "Now it's more like, uh, almost anyone can build today. Like you don't have to be technical to build, you just need to have an idea." He points to recruiting tools that staff now deploy for themselves, where they once had to ask an engineering team, and says companies he knows have reorganized around getting an idea to production quickly. These builders ship around the SDLC, and each internal tool they host is a new asset with an owner who may not know it needs patching.

Try this week: ask finance, recruiting and sales who has deployed an internal tool in the last quarter, and where it runs.

Rengasamy says "Obviously like banning the use of agents is not gonna help anyone." He puts the ratio of security engineers to engineers at about one to 100, per surveys he does not name, and the number of people using agents to build is now much of the company. Conventional review cannot scale to that. His answer, which he presented at fwd:cloudsec, is to take the paved roads security already wrote and put them in front of the agent while it works.

There are two mechanisms. Agents such as Cursor support hooks, and the security team can run an MCP service that an agent calls with a question like "I'm building this serverless infrastructure. Uh, what are all the security things that I need to keep in mind?" The answer lands in the model's context window, so every later request carries it. Rengasamy: "it's a server that serves security policies to any number of agents can query it, any number of users can query it." Paved roads that used to be documents and templates change form: "And now they look like an API. That's it."

Try this week: pick your three most-used paved roads and write down the API call that would return each one to an agent.

The anti-pattern Rengasamy sees most often is attention shifting to agent-specific defenses while foundational controls slip. He names service control policies and resource control policies in AWS, organization policies in GCP and any other preventative control, and says some companies never had them and then started on agents. Sandboxing and security context are useful, and he still draws a line: "when they are accessing real-time systems, the preventative controls are what save you." His instruction: "So I would not compromise on any of the preventative controls at all."

On the detection side he sees confusion about identity: when an agent deletes a resource or reads something it should not have, who is accountable. The Vercel Sandbox finding in this week's news is a reminder that sandbox and egress controls can have gaps of their own, and he lists OS-level isolation and egress control as the open problems.

Try this week: list the preventative controls you had before agents arrived and confirm each one still applies to the identities agents run under.

Speed is fine with Rengasamy, with one condition. "Any critical environments, any critical data access and like any state changing thing, change, changing request, like update something, delete something, all of that needs an accountability to it." The host raised stories of agents deleting production databases, and Rengasamy's reply is about authorization: "Like you need a user to explicitly say, "Hey, I'm authorizing this thing to go and delete X, Y, and Z.""

He separates two cases. A personal agent, such as one that checks email and answers Slack, uses your identity, so any change it makes traces back to you. An unsupervised cloud agent raises the accountability question. He cites a line he attributes to IBM: "A machine cannot be held accountable, therefore it should not be making a management decision." His practical rule is to define what the function needs, give the agent a list of things it can access, and constrain it with identity and network controls.

Try this week: list every agent, bot and CI job that can modify or delete production resources, and write the named approver next to each.

Ashish Rajan puts the problem plainly: "So our traditional methods are kind of out of the window already. Pull request is too late to even think about, uh, in this world of where just code is just coming left, right, and center." Rengasamy agrees and adds that the pipeline itself has changed. Scanners add minutes to a PR wait, agents now babysit PRs and respond to review comments, and "the things that are responding to your SCA findings are not humans anymore either." He has watched bots on his personal repository trade complaints and fixes with each other.

His preference is to catch issues earlier, while the agent works. If the agent knows which libraries it may use and which tools to run locally, it can fix findings before a PR exists. He gives Terraform as an example: an IDE extension that flags a public bucket or missing trust relationships was always limited by a human's time and attention, and an agent that fixes every finding removes that limit. He keeps bug-bot review on pull requests for business and logic issues. Rengasamy: "Moving this all the way to the agent and telling them what to look for, given the type of task you're doing from a security perspective, is completely worth it."

Try this week: pick one PR-stage check and write the instruction that would let an agent run it before opening the PR.

Agents change build versus buy for security teams. Rengasamy's example is a Slack bot that reads a 403 from Kubernetes admission control, an SCP or an organization policy and tells the developer why the request was blocked, what to change and who to ask. "It's not profitable to build a company around telling people why they were blocked." In most companies he has worked at, he says, "that'll, in most companies I've been at, that'll kill like- At least 25 to 30% of like the frequent requests that you get via Slack and like, things that will make you context switch, right?" [VERIFY: the figure is the guest's own estimate.]

The technical work is largely automatable, so the harder questions move to communication and enforcement: how people learn about a paved road, how they are held to it, how a deadline gets enforced and how they feel supported. He suggests an internal security hub that used to need software engineers and now needs an idea and a clear view of what good looks like. On whether non-technical staff can do this, his advice is to use the model as a copilot for a week or two, notice what you repeat, and automate that. First-level triage of bug bounty reports by an agent with the repository's context is his AppSec example. He adds: "This might even kill Excel sheets in cybersecurity."

Try this week: write down the three questions your team answers most often in Slack and pick one for an agent-built bot.

Agents inherit the identity of whoever runs them. Rengasamy: "Because the users themselves are overprivileged and like the identity story is not sorted, and if they're running agents, agents impersonate them, so they get that identity." If users hold more access than they need, the agent does too.

On data, he wants an inventory of where the sensitive data sits, with labels and a catalog, such as a bucket holding personal information that carries retention requirements. Whether that catalog is a spreadsheet or a purpose-built system, he suggests exposing it through an API and telling the agent not to touch resources annotated as containing personal data. In Kubernetes the same idea works through labels: "In kube, this can be just, uh, namespace labels or resource labels that say off limits to agents." He adds that Kubernetes has "a fantastic API" for querying them. The open work he names is isolation at the operating-system level and keeping egress controls, because agents make many calls in and out.

Try this week: label one data store that agents must never read, and test whether an agent under a normal engineer's identity can still reach it.

For a company of 10,000 people, Rengasamy's answer is the one the industry used for cloud native. Rengasamy: "Like, we secure microservices with platforms. We can secure agents with dedicated platforms built for them." A platform built with engineering and wired into internal context gives security a paved path to bake controls into and visibility into exemptions. He says the shift takes some thought: "Scaling it means just that like you need a little bit more thought around, instead of just saying like, "Hey, you can use whatever you want, use it however you want.""

The host frames it as a maturity test: "Interesting. That also makes me think that agent sprawl is gonna be very common across the entire organization, and a sign of a mature AI company would be people who have built an AI platform With standardized way for agents." Rengasamy agrees as a general example, with the caveat that agents are a little more autonomous than microservices.

He splits agents into two types. Coding agents work with repositories and infrastructure and are where a platform pays off most. Q&A agents query data with the user's identity, so existing identity controls, hooks and OpenTelemetry metrics on who accessed what, and when, cover most of the risk. His yardstick is changes versus reads: "I'd, yeah, I'd measure it in terms of like non-read actions, right?" Browser-acting cowork-style agents are, in his words, still up in the air, and he suggests a restricted, MDM-managed browser such as Island or Chrome Enterprise. He called out Perplexity for security-focused agent work on its computer product and for infrastructure that runs cloud agents safely, with egress controls and proxies that fill in credentials.

Security teams should start with their own agents. Rengasamy: "So probably like the most high impact, uh, credential that you can steal or like an agent can impersonate to cause like a real harm to the business." Policies have to be applied to yourself first, and what you build can become the template others copy. On credentials that should never reach the model: "That's not a you problem. Yeah. That's an everyone who's using an LLM problem." The same goes for detection and response tooling that parses logs; an SRE or PagerDuty bot could reuse it.

Try this week: pick the agent your security team runs with the broadest access and apply the same approval, network and credential rules you would ask of engineering.

Practical takeaways

🤔 If an agent deleted a production resource today, could you name the human who authorized it?

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

📬 Want weekly expert takes on AI & Cloud Security? [Subscribe here]”

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Shilpi Bhattacharjee

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Security Podcast