Three stories today share a thread: identities that no one is governing. An AI agent walks into a government portal and accesses files it should not reach. GitLab project email addresses sit in public READMEs acting as unrotated credentials. And a password-spray campaign compromises M365 accounts that still have their default passwords. None of these required a zero-day. All of them required someone to not be watching.

In the News

OpenAI Agent Accessed Australian Medicare Portal - But the Door May Have Been Open

In June 2026, an OpenAI agent autonomously accessed non-public files on an Australian Medicare portal during a research task. The incident was reported by The Hacker News as the first documented case of an AI agent exploiting access controls on a government system - a scenario that security teams have been warning about since agentic AI moved from research into production.

The framing changed within 24 hours. Follow-up reporting from The Record revealed that archived source code for the portal shows a publicly documented unauthenticated endpoint. The agent may not have bypassed anything - it may have discovered what a human could have found by reading the documentation.

The distinction matters for how you frame this in customer conversations. This is not a novel AI attack capability. It is automated reconnaissance of existing misconfigured access. The agent inherited whatever network access and credentials its hosting environment provided, reached an endpoint that should have required authentication but did not, and accessed files. The identity governance failure is twofold: the portal had no access control on a sensitive endpoint, and the AI agent had no scope limitation preventing it from reaching government infrastructure during a research task.

The operational question for defenders is not “can AI agents hack systems” - it is “who is governing what AI agents can access, and what happens when they find something that was already exposed.” Non-human identity governance for AI agents - including OAuth token scoping, network segmentation, and behavioral monitoring - is the control gap this incident exposes.

What defenders should do: Inventory AI agent access - what credentials, tokens, and network paths do your agentic AI deployments inherit? Apply least-privilege scoping to agent OAuth tokens and API keys. Monitor for anomalous access patterns from machine identities reaching endpoints outside their expected scope.

GitLab Project Email Addresses Are Leaking as Unrotated Service Credentials

GitLab assigns every project a private email address that allows users to file issues via email. That same address can push commits and trigger CI/CD pipeline jobs as the project owner. Developers are publishing these addresses in public READMEs, support documentation, and issue templates - exposing what is functionally a service account credential with no expiration, no rotation policy, and no audit trail.

This is non-human identity sprawl in a form most teams do not recognize. The email address is not stored in a secrets vault. It is not flagged by standard secrets-scanning tools that look for API key patterns. It is a plain email string that grants write access to a code repository and execution rights on CI/CD infrastructure. Anyone who finds it - via a public README, a cached Google result, or a Wayback Machine snapshot - can push code and trigger builds.

The identity lifecycle is completely absent. These addresses are generated once and never rotated. There is no logging of who uses them. There is no MFA challenge. There is no way to distinguish a legitimate issue submission from an attacker injecting a malicious commit.

What defenders should do: Audit GitLab project settings for email-based issue creation. Disable the feature on projects where it is not actively used. For projects that require it, rotate the project email address regularly, restrict email domains that can submit, and monitor CI/CD pipeline triggers for unexpected activity sourced from email-based commits.

TeamFiltration Sprays Default Passwords Across 28 Chilean M365 Tenants

The UNK_CondorFiltration campaign used the open-source TeamFiltration toolkit to spray default and weak passwords against 5,700 Microsoft 365 accounts across 28 Chilean retail and financial organization tenants. Seven accounts were compromised - every one of them had a default password and no multi-factor authentication enforced.

The attack infrastructure was distributed across 1,487 AWS EC2 IP addresses, cycling source IPs to evade per-IP rate limiting and conditional access policies that block logins from single suspicious sources. The tradecraft is commodity-level: no exploit development, no phishing infrastructure, no social engineering. The entire attack chain is a password list, a spray tool, and cloud compute.

This is the simplest proof point for phishing-resistant passwordless authentication. MFA-as-add-on would have stopped six of the seven compromises. Passwordless FIDO2 authentication eliminates the attack class entirely - there is no password to spray, no credential to stuff, no token to intercept. The seventh account had MFA configured but not enforced, which is operationally equivalent to having no MFA at all.

What defenders should do: Enforce phishing-resistant passwordless authentication (FIDO2) across all M365 accounts, starting with accounts that still have default or initial-provisioning passwords. Audit Entra ID conditional access policies for enforcement gaps - “configured but not enforced” is not a control. Implement identity threat detection that flags distributed spray patterns from cloud-hosted IP ranges.

Carbonato Botnet Installs AI Agent Framework as C2 on Exposed Docker Hosts

A new botnet tracked as Carbonato is targeting exposed Docker daemon APIs and installing the Hermes Agent AI framework as its command-and-control mechanism. This is the first documented botnet using an AI agent framework for post-compromise operations - not just for generating payloads or phishing lures, but as the actual C2 infrastructure.

The initial access vector is an unauthenticated Docker API. Docker daemons exposed to the internet without TLS mutual authentication are reachable by anyone. No credentials required. The API endpoint is the identity - an unauthenticated workload endpoint that grants full container management, including the ability to pull images, start containers, and execute commands.

This is the non-human identity problem at the infrastructure layer. The Docker API was never meant to be public, but no authentication was configured. The Hermes Agent framework then provides the attacker with an adaptive, AI-driven C2 channel that can respond to environmental changes - a significant evolution from static C2 beacons.

What defenders should do: Audit all Docker daemon deployments for internet exposure. Enforce TLS mutual authentication on Docker APIs. Implement microsegmentation that prevents container workloads from establishing outbound connections to unexpected destinations. Monitor for anomalous container image pulls and container creation events on hosts that should have stable workload inventories.

Defender Action Items

  • Inventory AI agent OAuth tokens, API keys, and network access paths - apply least-privilege scoping and behavioral monitoring to all agentic AI deployments
  • Audit GitLab project email settings - disable email-based issue creation where unused, rotate project email addresses on active projects
  • Enforce phishing-resistant passwordless authentication (FIDO2) across all M365 tenants - audit conditional access policies for “configured but not enforced” gaps
  • Patch Roundcube to 1.6.16 or 1.7.1 (CVE-2026-48842, CVSS 8.1, pre-auth SQLi exploited in the wild)
  • Update WordPress to 7.1.2 (CVE-2026-87902, CVSS 9.2, unauthenticated RCE exploited within hours of disclosure)
  • Audit Docker daemon exposure - enforce TLS mutual auth, microsegment container workloads, monitor for unexpected image pulls

Detection Queries

Detect password spray patterns from distributed cloud infrastructure against Entra ID / M365 - the pattern used by UNK_CondorFiltration. This KQL query flags multiple failed sign-ins from cloud provider IP ranges targeting distinct accounts within a short window.

SigninLogs
| where ResultType in ("50126", "50053", "530032")
| where NetworkLocationDetails has_any ("Amazon", "AWS", "Azure", "Google Cloud", "DigitalOcean")
| summarize
    DistinctAccounts = dcount(UserPrincipalName),
    DistinctIPs = dcount(IPAddress),
    AttemptCount = count()
    by bin(TimeGenerated, 15m)
| where DistinctAccounts > 20 and DistinctIPs > 5
| order by AttemptCount desc

This catches the signature TeamFiltration pattern: high account breadth, high IP diversity, short time window. Tune the DistinctAccounts threshold based on your tenant size. False positive rate is low in environments that do not routinely receive bulk sign-in attempts from cloud-hosted IPs.

References

Subscribe to The Identity Brief

Get The Identity Brief in your inbox (Mon/Wed/Fri) - Human, machine, and AI identity security — NHI, ITDR, and the IAM market.