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.

Our product team constantly runs experiments, turning features on and off with flags that are increasingly evaluated or executed by AI agents. Orca doesn’t try to live in the feature-flag layer; instead, it watches the underlying cloud identity and the agent posture. When an experiment gives an agent broader access than intended, or opens up a test path to sensitive data, Orca picks it up on its next assessment of the cloud and agent surface and flags it. Developers don’t have to change how they ship experiments, but security can still see where agent-driven flags might create unexpected exposure.