AWS and GitLab fixed flaws that could expose the keys to AI agents

The 30-second briefing

What happened? AWS disclosed three flaws in Loom, software for building and managing AI agents. GitLab disclosed a separate flaw in its self-hosted AI gateway. Fixed versions are available.[1][7]

Why does it matter? These systems can sit between an AI agent and the tools, credentials, cloud permissions and internal services it may use. A failure there can become an authority and evidence problem—not merely a chatbot error.

Was anyone harmed? The reviewed sources do not report an exploited deployment, identified victim, financial loss or service interruption.

Did an AI escape? No reviewed source reports that a model found or used these flaws, selected a victim, replicated itself or resisted shutdown.

What should happen now? Inventory, patch, restrict, isolate and preserve independent evidence. Each step should leave a receipt that executives and auditors can verify.

Rapid research notice: This alert was produced through automated monitoring and model-assisted analysis of public sources. It may contain errors, omit relevant evidence or change as new information becomes available. It is not an audit, rating, prediction, or legal, investment, regulatory, accounting, operational or cybersecurity advice. Material corrections would be logged on the public page.

Imagine the digital control room

An ordinary employee may have access to one application. An AI agent can be connected to many: files, email, databases, cloud services and outside tools.

The control plane is the digital control room that decides which agent may use which tool, what credentials it receives and what actions it may take. If that control room fails, an attacker may not need to fool the AI at all. The machinery around it may already hold the keys.

In the most serious Loom condition, a backend exposed to the network without a configured identity provider could treat an unauthenticated network client as an administrator. AWS says that authority included registering tool servers, reading stored integration credentials and rewriting cloud-access policies attached to managed-agent roles.[1][2]

In plain English: under the stated configuration, an unauthenticated network client might not merely communicate with an agent; it could gain administrative control over the machinery that determines what the agents are allowed to do.

Why a finance leader should pay attention

Financial institutions already understand that the person initiating a transaction should not also control every approval, record and reconciliation.

The same principle should apply to AI infrastructure.

If one agent control plane can initiate an action, select a credential, change tool permissions, reach internal services and exclusively create the record used to explain what happened, a compromise could affect both the action and the evidence describing the action.

That does not mean these flaws corrupted a ledger or moved money. The reviewed sources report no such event. It means the architecture matters wherever agents may eventually connect to payments, customer records, approvals, trading support, claims, treasury operations or other consequential systems.

The board-level question is therefore not simply, “Is the AI model safe?” It is:

Who controls the system around the model, what authority does that system hold, and would independent evidence survive if it were compromised?

Four failures in plain English

1. The front door could be open

System: Loom for AWS before version 1.6.1.
Condition: The backend was reachable over a network without a configured identity provider.
Potential consequence: An unauthenticated network client could obtain administrative authority, including tool registration, stored integration credentials and managed-agent cloud-role policies.
Fix: Version 1.6.1 addressed the issue; AWS recommends version 1.7.0.[1][2]

The CVE record assigns the disclosed condition a CVSS 3.1 score of 10.0. The public record does not say every Loom installation was exposed; both network reachability and missing identity configuration mattered.[1][2]

2. A trusted setup screen could send secrets to the wrong place

System: Loom for AWS before version 1.7.0.
Condition: A user with privileged tool- or remote-agent-management access supplied manipulated identity-discovery information.
Potential consequence: The backend could send a client secret or another user’s access token to an outside destination.
Fix: Upgrade to version 1.7.0.[1][3][5]

The affected privileges were called mcp:write and a2a:write. The business meaning is more important than the labels: permission to connect a tool or remote agent could become a route for redirecting secrets.

3. A tool connection could reach private machinery

System: Loom for AWS before version 1.7.0.
Condition: A user with the same privileged connection-management access supplied a crafted destination.
Potential consequence: The platform could request internal services, including the service supplying cloud-container credentials, and return the response.
Fix: Upgrade to version 1.7.0; restrict the relevant privileges while upgrading.[1][4][6]

The practical lesson is that a web address entered into an agent platform is not harmless text: it can cause the platform to request internal services that are not intended to be reachable through that workflow.

4. A workflow template could become a server command

System: Specified versions of GitLab Self-Hosted AI Gateway.
Condition: An authenticated user with Duo Agent Platform access submitted a crafted flow configuration.
Potential consequence: The configuration could escape the prompt-template sandbox and lead to command execution on the gateway.
Fix: GitLab released versions 19.2.4, 19.3.2 and 19.4.1; it says hosted gateways were already fixed.[7][8]

GitLab assigns the flaw a CVSS 3.1 score of 9.9. At the cutoff, NVD had marked its record as awaiting enrichment while reproducing GitLab’s affected versions and vulnerability description.[8][9]

Serious infrastructure flaws—not evidence of a rebellious machine

The simpler explanation is serious enough: software surrounding AI agents contained familiar vulnerability classes—missing authentication, unsafe outbound-request handling and improper template processing that could lead to command execution.[1][7]

Ignoring the flaws because they are “ordinary cybersecurity,” however, would miss their architectural significance: in Loom, the affected control plane could govern tool registrations, integration credentials, cloud-role policies and access to internal services; in GitLab’s gateway, the separate flaw could permit command execution on the gateway.[1][7]

The reviewed sources do not report autonomous exploitation or model loss of control. The lesson is about the authority concentrated around agents and the controls protecting it.

What leaders can do—and what proof to request

Today: establish exposure

• Inventory Loom deployments, including experiments, old images, forks and derivative projects.
• Confirm Loom version 1.7.0 or later.
• Determine whether any backend was reachable beyond the local machine before identity was fully configured.
• Identify affected GitLab Self-Hosted AI Gateways and confirm a patched release.
• Preserve relevant logs before routine retention or system changes remove them.

Required receipt: A dated, signed inventory listing deployment owner, version, network exposure, identity-provider status, patch result and unresolved exception.

This week: reduce the blast radius

• Limit who can register tools, remote agents and identity connections.
• Prevent agent workloads from reaching cloud credential services and private administrative networks unless explicitly required.
• Allow outbound connections only to approved destinations, with destination checks repeated after address resolution and redirects.
• Broker short-lived, narrowly scoped credentials instead of storing durable secrets in general orchestration software.
• Treat a new tool, remote agent or workflow definition like a privileged software deployment—not a harmless preference setting.

Required receipt: A reviewed privilege report, approved destination list, credential-lifetime report and test showing that prohibited internal destinations are denied.

For the operating model: separate action from evidence

• Keep consequential approval authority outside the agent runtime.
• Send audit records promptly to retention-controlled storage administered separately from the control plane.
• Preserve external receipts from banks, custodians, platforms and counterparties.
• Use signed, sequenced and cryptographically linked checkpoints so that missing, reordered or conflicting histories are more likely to be detected.
• Test recovery without restoring revoked credentials, old permissions or superseded approvals.

Required receipt: An independently verified evidence export and recovery-test record showing which actions, approvals, credentials, policy versions and external results can be reconstructed.

These measures cannot prove that every original instruction was true or wise. They can make silent alteration, selective deletion and retrospective rewriting materially harder.

Five questions for the next executive meeting

1. Where are our AI agents actually running, including experiments?
2. Who can connect a new tool or outside agent, and does that require independent approval?
3. What credentials and internal systems can the control plane reach?
4. Could the control plane alter or erase the only record of what it did?
5. Can we stop it, revoke it and reconstruct events if the primary system is unavailable or untrusted?

A team that cannot answer those questions cannot yet demonstrate that it understands or controls the authority it has delegated.

What remains unknown

The reviewed sources do not establish:

• exploitation in the wild;
• a victim or affected customer;
• financial loss, data loss or service interruption;
• autonomous discovery or exploitation by an AI model;
• how many deployments met the vulnerable conditions;
• whether historical audit records can identify prior misuse;
• whether every fork or derivative project has incorporated the fixes.

The absence of reported exploitation in the reviewed sources is not proof that no deployment was exposed or misused; it means the reviewed public record is incomplete.

The conclusion

The immediate story is not that AI escaped.

It is that, under documented conditions, three Loom flaws could expose administrative authority, credentials, cloud-role policies or internal services, while the separate GitLab flaw could permit command execution on the gateway.[1][7] AWS and GitLab have supplied fixes.[1][7]

The executive task is now to determine where these systems exist, what authority they hold, whether the fixes landed and whether trustworthy evidence would survive a compromise.

That is the threshold between experimenting with AI agents and governing them.

About this alert

This proof consolidates public-source developments in the 48 hours ending 3 October 2026, 01:44 UTC. It separates infrastructure vulnerabilities from claims about autonomous model behavior and translates the disclosures into identity, authority, credential, network and evidence questions for non-technical decision-makers.

For research and executive education only. Not legal, investment, regulatory, accounting, operational or cybersecurity advice.