Cloud platform

Permission and credential review for AWS Bedrock AgentCore

Review AWS Bedrock AgentCore execution roles, tool permissions, and possible credential exposure. Do not use version-based fleet scoping until reliable service, deployment, or affected-version identifiers are available, and do not treat remediation as confirmed without primary vendor evidence.

Contain and investigate AWS Loom identity exposure

Organizations using affected Loom deployments should restrict ingress and untrusted registrations, preserve application and cloud audit evidence, revoke exposed integration tokens, remove unknown registrations, review managed-role policy history, and install the vendor-confirmed fixed release.

Identity and recovery controls for compromised Azure service principals

Affected Azure tenants should revoke exposed reusable credentials, move toward managed or narrowly federated identities, reduce standing privileges, separate destructive and recovery authority, protect backups, and monitor anomalous service-principal behavior.

Azure service-principal permissions and recovery safeguards

Organizations should review effective Azure permissions for service principals, including inherited and group-based access; preserve and correlate identity and activity telemetry; reduce unnecessary destructive privileges; and test restoration from an immutable recovery copy protected from production service-principal deletion authority.

Protect and monitor AWS root accounts

Organizations should verify phishing-resistant protection for AWS management-account root users, remove unnecessary root credentials and access keys, and alert on every root event. Failed spraying alone does not prove compromise, but unexpected successful authentication or subsequent root activity should trigger incident response.

Prioritize AI platform risks by exposure to secrets, execution, and automation

→Inventory and block public access to MCP, local LLM, JSON-RPC, assistant configuration, and .env paths; validate vendor applicability before patching or isolating affected AI platform deployments; audit Langflow and similar tools for AWS metadata, secrets, CI/CD, and internal API access; rotate keys only if suspicious access appears.

Prioritize AI-platform and agent findings when they create a path to credentials, cloud metadata, code execution, repositories, or privileged automation. Block exposed MCP, local LLM, JSON-RPC, assistant-configuration, and .env paths; validate vendor applicability and local exposure before product-specific patch or isolation claims; rotate keys when suspicious access is indicated.

Handle reported cloud and source-control secret exposures as control-plane credential incidents

→Treat reported AWS, GitHub, GovCloud, Azure, and Accenture-style secret exposures as cloud control-plane credential incidents: rotate AWS/Azure keys and tokens, invalidate sessions, contain high-risk CI/CD and automation paths, review IAM privilege chains across S3/ECS/SQS/source control, quarantine exposed repositories and forks, and validate whether claimed leaked secrets were usable.

Reported cloud, source-control, and CI/CD secret exposures should be handled first as control-plane credential incidents: rotate or revoke keys and tokens, invalidate sessions, contain high-risk automation, review IAM and source-control privilege paths, and quarantine exposed repositories where needed. Third-party leak claims, live usability, and downstream client impact should be validated before being stated as confirmed.

Treat Amazon Q/AWS developer-tool malicious-repository exposure as a same-day affected-fleet action

→For affected developer fleets, inventory Amazon Q Developer and AWS Language Server usage, apply available updates or disable affected tooling, review untrusted repositories for reported `.amazonq/mcp.json` or unexpected MCP/tool execution, check for exposed cloud or SSH credentials, and restrict AI coding agents from auto-loading untrusted workspace tool configuration.

Organizations using Amazon Q Developer or AWS Language Servers should treat reported malicious-repository/tool-configuration exposure as a same-day developer-fleet check: inventory the tooling, apply available updates or temporarily disable affected integrations, review untrusted repositories for `.amazonq/mcp.json` or unexpected MCP/tool execution, check for exposed developer cloud or SSH credentials, and prevent AI coding agents from auto-loading untrusted workspace tool configuration.

Package Compromise Should Trigger CI/CD Secret Rotation and Build Containment

→For suspected Miasma/Shai Hulud-style package compromise, freeze suspicious dependency changes, block affected package execution paths, audit npm/PyPI/Go lockfiles and GitHub Actions, rotate CI/CD, GitHub, package-manager, AWS and Redshift secrets, and inspect developer machines and runners for secret theft.

When package compromise is suspected in npm, PyPI, Go or CI/CD paths, freeze suspicious dependency changes, contain affected build paths, rotate workflow, package-manager and cloud secrets, and inspect runners and developer endpoints. Use known or suspected indicators pending local validation; do not imply this packet contains a complete IOC list.

Suspected AWS AiTM Exposure Requires Same-Day IAM Containment

→Treat suspected AWS AiTM credential/MFA capture as potential active session or token exposure: revoke sessions, invalidate tokens, rotate access keys and console credentials, inspect IAM persistence and console/API activity, and harden conditional-access and break-glass controls.

When AWS AiTM credential or MFA exposure is suspected, contain as if active sessions or tokens may be exposed: revoke sessions, rotate credentials and keys, inspect IAM changes and console/API activity, then harden access controls.