Orca flagged malicious files and suspicious workflows across our workloads that none of our other tooling had caught, including scenarios where an abused AI agent could have been used to plant or trigger malware. It goes beyond simple hash matching, picking up things like cryptominers and web shells that agents might deploy or invoke as part of a compromised toolchain. Because scanning happens off the workload at the storage and configuration layer, there’s nothing for the malware to hide from on the box itself, and it also covers hosts and agent-linked paths we never would have pointed a dedicated scanner at.

We had a vague sense that credentials and secrets were scattered across our environment, but we didn’t have a clear map of which ones agents could actually see. Orca surfaced hardcoded API keys, SSH private keys, and database credentials in places agents or their tools might read—config files, storage buckets, and logs. It doesn’t just pattern-match; it uses entropy and the surrounding context to decide whether a string is truly a secret, which keeps the noise down. Seeing each secret in the context of agent reachability made it clear which exposures could be triggered by agents and needed immediate cleanup.

Having Orca scan our infrastructure as code and our pipelines has been a genuine shift-left win for the AI agents. We started catching templates and configuration snippets that would have granted agents broad, long-lived permissions or exposed new agent endpoints before any of those changes ever deployed. Because Orca ties these IaC findings back to the same risk model it uses for the running environment, we can clearly see that a misconfiguration flagged in code is the same kind of agent exposure we’d otherwise be chasing down in production later.