Vulnerability intelligence · Reviewed security advisory
AWS Loom: who can change the tools your AI agent trusts?
The Loom security bulletin is a reminder to review the people and services that register tools, choose destinations and hold integration credentials. Those settings carry real business authority.
By Colin Ambani Njau ·
From the 5 October scheduler brief; AWS bulletin published 2 October 2026.
The verified position
AWS’s 2 October bulletin describes CVE-2026-103956, CVE-2026-103957 and CVE-2026-103958 in Loom for AWS. The first concerns administrative access where no identity provider was configured and was addressed in version 1.6.1. The other issues concern OAuth credential disclosure and connections to internal destinations; AWS identifies 1.7.0 as the resolution.
The bulletin recommends upgrading, including patches in derivative code, rotating configured OAuth client secrets and revoking and re-issuing access tokens active during the affected window. It also calls for CloudTrail review if container role credentials were accessed. These are vendor instructions for affected deployments, not evidence that every Loom installation was compromised.
The settings page is part of the security boundary
A business may carefully approve what its AI assistant is supposed to do, then overlook who can register a new tool or change the service behind an existing connection. That configuration changes the assistant’s authority before the model makes its next decision.
For example, a hypothetical finance assistant may have permission to retrieve invoice data. If someone can redirect its integration to another destination, the approved business purpose no longer describes the actual data flow. A permissions review should include the configuration editor as well as the tool caller.
Ask four concrete questions
Who can create a connection? Who approves the destination? Where are integration credentials available? What evidence records a change? Name a responsible person for each answer. Treat missing authentication as a release issue rather than a configuration detail to tidy up later.
After applying the appropriate vendor fix, review credential exposure separately. Patching a software path does not undo earlier disclosure of a secret. Preserve relevant logs and follow the vendor’s incident-specific guidance when exposure is suspected.
Connect the fix to a repeatable assessment
Use separate test identities to inspect the tool-registration lifecycle: create, approve, persist and invoke. Keep all testing within an agreed environment. A useful outcome records which identity was denied, which operation was attempted and whether the denied operation produced any side effect.
Pentriarch’s MCP static scanner can inspect the declared tool surface and compare manifests with a previous baseline. It cannot replace an identity provider or prove that every administrative API is correctly authorised. Combine relevant static inspection with a scoped assessment of the application’s actual permission checks, then retain remediation and retest evidence.