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.

Orca gave us a much clearer picture of where sensitive data actually lives in relation to our AI agents. It surfaced PII in storage, secrets in places agents might read, and old database snapshots sitting in accounts that newly created agents were able to reach. The real value is the context: each finding shows what the data is, whether it’s exposed, and which agents and identities can access it. That turned what could have been an overwhelming inventory into a clear, prioritized list of data our agents should never be able to touch, along with the paths we needed to close.

Our finance and enterprise risk teams wanted to understand AI agent risk in business terms, not just issue counts or an abstract idea of "agent exposure." Orca’s context—what data an agent can touch, whether it can reach internet-facing services, and which identities and systems sit behind its paths—lets us group agent-driven risks around business-critical assets and regulated workflows. It’s not a full quantitative risk engine, but it has given us a structured way to discuss which agent behaviors matter most to revenue, compliance, and our contractual obligations.