Notes from inside.

Across 41 engagements this year, the single most reliable path to tenant-wide impact wasn't an exploit — it was an identity provider configured like nobody believed it was load-bearing. Groups synced from HR systems, SCIM tokens in CI variables, MFA policies with a "break-glass" account nobody remembered.

In the median case the swarm needed only two hops: a leaked OAuth client secret (usually in a stale integration or public repo), then group self-service or SCIM abuse to mint a privileged session. No CVE required. The exploit was the org chart.

$ swarm chain replay --engagement 1847
# foothold: leaked oauth client_secret (public repo, age 14mo)
token = sts.exchange(client_id, secret, scope="scim")
idp.groups["global-admin"].members += operator_session
→ tenant admin in 2 calls. no exploit primitive needed.

What to fix first: inventory every SCIM token and OAuth client with write scope; alert on group-membership changes to privileged groups; kill break-glass accounts you can't name a person for.

We ran an aggregate study of recon output across active engagements: ~41k discovered subdomains per client median, of which ~8% resolved to assets the client's own inventory didn't know about. Forgotten doesn't mean small — the unknown slice included production databases, admin panels, and an entire retired-but-running Kubernetes cluster.

Three patterns produced most of the critical findings:

• Review apps that never died. Ephemeral PR environments with production database credentials, alive for months after the PR merged.
• Acquisitions. Inherited domains pointing at infrastructure nobody in security had ever logged into.
• Vendor sprawl. Third-party panels on customer subdomains, running versions from three years ago.

Continuous enumeration isn't a nice-to-have. The surface you tested in March isn't the surface you're defending in November.

The most instructive chains our agents build look less like classic exploitation and more like a burglar with a master key ring: every hop is a legitimate feature used illegitimately. Slack apps with files:read. Calendar webhooks that leak meeting links. Docs "anyone with the link" shares indexed by the org's own search.

We teach the swarm this style deliberately — it's what a patient human intruder does, and it's what your detections are least likely to flag, because every request is authenticated and on-platform.

If your threat model only counts shells and CVEs, it will miss the paths that are already open.

CVSS answers "how bad is this bug in the abstract." The question a CISO actually has is "how far into my company does this get someone." Those are different numbers, and the second one is only measurable by walking the path.

Every Yegg finding ships with a demonstrated chain and an impact statement — "read access to the customers table for 2.1M rows" — rather than a 9.8 next to a theoretical. Severity is what the path proves, not what the primitive scores.

The side effect our clients notice first: the report gets shorter and the fixes get faster. Nothing to argue about; the proof is attached.

Our clients are deploying agents with tool access — email senders, ticket writers, code executors. The attack surface isn't the model's weights; it's the permission boundary around the tools. So we attack that boundary.

In scoped engagements, the swarm chains indirect prompt injection (poisoned docs, emails, web pages the agent will read) into tool calls the agent's operators never intended: exfiltrating context windows, minting tickets with attacker-controlled content, reaching for credentials in the agent's environment.

The defense isn't "better prompts." It's the same discipline as any other principal: least-privilege tool scopes, human approval for irreversible actions, and treating agent output as untrusted input — everywhere.