Your AI agents have more access than anyone.
Nobody’s watching what they do.

Oryo blocks, warns or logs, decided per policy. A block stops the request on the laptop before it reaches the model, and the person sees a notification with the policy’s name and reason. A warning shows the same notice and lets the request through. Every decision is logged.

Yes. A disallowed-agents policy works as a kill switch: name the agent and every request it makes is blocked on every device, from its next request. The same works for an MCP server, a person or personal accounts. It stops the agent’s AI traffic; it doesn’t end the process on the laptop.

These map to the OWASP Top 10 for Agentic Applications: the kill switch to ASI10 (rogue agents), blocking a person or account to ASI03 (identity and privilege abuse), and allowing only approved tools to ASI02 (tool misuse).

Secrets (221 rules), personal data, prompt injection in tool results and documents, and your own regex rules. It also enforces allow and deny lists for agents, models, MCP tools and identities. Microsoft Purview policies can be checked too.

The sensor works at the process and network level, not in a browser extension. A block applies in every browser, desktop app and command-line agent. New AI services are found on the device automatically, and people without admin rights can’t uninstall the sensor.

New AI services show up in the register as soon as they’re seen. With an allow-list policy, anything not on the list is blocked until someone approves it.

Yes. Oryo reads the signed-in account from the request. A domain allow-list policy then blocks or warns on accounts outside your company domains, per agent.

The person, device, process (binary, pid and parent), agent, model, the tools offered in the request, the policy and the decision. For violations, the full conversation is kept.

No alerts fire until you turn a policy on. Webhooks carry policy violations only, not every request. Most teams start in log-only mode, then scope policies to the agents and teams that matter before they enable warnings and blocks.

Every violation is sent as a signed webhook (HMAC-SHA256) with retries, ready for Splunk, Sentinel, Tines or anything else that takes a webhook.

{
  "delivery_id": "b1e4…",
  "events": [{
    "type": "violation.detected",
    "occurred_at": 1792351327000,
    "data": {
      "violation": { "action": "block", "severity": "high",
                     "reason": "AWS secret key in tool result",
                     "trace_id": "01a13764…" },
      "policy":   { "name": "Secrets in prompts and tool results" },
      "agent":    { "name": "Claude Code" },
      "identity": { "name": "dana@acme.com" }
    }
  }]
}

Text is extracted from PDF, Word, Excel and PowerPoint files and checked by the same policies. Images are not scanned. For violations Oryo keeps the file’s type, size and fingerprint, not the file itself.

Signed packages for each platform: a notarized macOS package, a Windows MSI and Linux deb and rpm. Push them through the MDM you already use. Installs are silent and devices register themselves, with no per-user tokens.

macOS 13 and later, Windows 10 and 11 (x64), and Linux. Phones and tablets aren’t covered today.

It runs as a service, needs admin rights to install, and adds a local root certificate so it can read requests to AI services on the device. Push the certificate with your MDM. Firefox keeps its own certificate store.

Requests to AI services are inspected and sent for a policy decision. To find new AI services, the sensor watches each new destination on the device for 15 minutes. Only the address of a likely AI endpoint is reported; the content of other traffic never leaves the laptop. You can exclude hosts and apps.

Each request is held for up to 30 seconds while Oryo decides. If the decision service is unreachable, traffic fails open by default so work doesn’t stop. You can switch that to fail closed.

Add the Oryo service to your EDR or antivirus allow list, as you would any agent. Tools that pin their own certificates, like some remote-support apps, can be excluded by host or process.

The sensor updates itself, and you can pin a version. Self-hosted and air-gapped sites mirror the packages and roll them out on their own schedule.

Okta and Microsoft Entra, for users and departments. Each device also registers to a person, so attribution works before the IdP is connected.

For ordinary requests, a fingerprint of the prompt, its classification, and who, what and where: person, device, process, agent and model. The full conversation is stored only when a policy is violated.

Records are kept in Oryo for 30 days, then deleted. Every violation is also sent to your SIEM as a signed webhook, so you can keep it there for as long as your audit policy requires.

In Oryo’s cloud in the US, or self-hosted on your own Kubernetes. Self-hosted, nothing leaves your environment, which also covers EU residency.

In Oryo’s cloud, prompt classification and the optional AI-based data check use a model on AWS Bedrock. Secrets, personal-data and prompt-injection detection run inside Oryo. Self-hosted, you connect your own model or run without one; every local check still works.

No. Oryo reads requests to AI services on their way out of the laptop. It doesn’t log keystrokes, record screens or scan files on disk.

Dashboard users are admins or read-only. Full conversations exist only for violations, so day-to-day prompts aren’t there to browse.

Oryo isn’t SOC 2 or FedRAMP certified today. Teams in regulated environments self-host, so data stays inside their own boundary and controls.

Yes. The AI register lists agents, models, MCP servers and tools, by person and team, approved or not, including personal accounts on work laptops.

Yes. Allow lists by agent, model, MCP server or identity block anything new until it’s approved.

Policies apply by user identity, department, agent, model or MCP server, and specific identities can be exempted.

One record per decision, with the controls it satisfies. For example:

Records live in the console and arrive in your SIEM.

Each decision maps to AIUC-1, MITRE ATLAS and NIST 800-171. The AIUC-1 view lists the whole standard and shows which requirements runtime controls give evidence for and which are process work outside Oryo. Policies also name the OWASP Top 10 for Agentic Applications risk they address: tool misuse (ASI02), identity and privilege abuse (ASI03) and rogue agents (ASI10). NIST AI RMF, ISO 42001 and the EU AI Act aren’t separate views today.

Yes. Tokens, prompts and active users, by person and by tool, so you can see which paid Copilot and ChatGPT seats sit unused and who uses personal accounts instead. Token counts are close estimates, not billing figures.

Yes. Each threat Oryo tracks shows as covered, partial or exposed, based on the policies you have turned on, with what each one caught in the last 7 days. It tells you what to switch on next.

No. Most teams run in log-only mode first to see what’s in use, then switch on warnings and blocks policy by policy.

Any process on the laptop that calls a supported AI service, including Claude Code, Codex and Copilot, plus custom harnesses, Python and Node scripts and cron jobs. Each shows up as itself, with its binary, parent process and repo.

The tools offered to the model in each request, every tool call the model makes, and each tool result before it goes back to the model. For each agent you see which MCP servers and tools it can reach. Tool allow and deny lists block a request that carries an unapproved tool, and a cap limits how many tools one agent can carry.

Only requests to AI services are held for a decision. Everything else goes straight out, so builds, package installs and git are untouched.

The Linux package installs on servers and build runners or in your base images. Machines without a sensor aren’t covered.

Not the call itself. Oryo records every tool call the model returns, but it doesn’t hold the response. What it stops is the next step: the tool’s result goes back to the model in the next request, and that request is checked and can be blocked before the model sees it. Tool allow and deny lists also block a request that offers an unapproved tool in the first place.

Oryo covers agents on machines that run the sensor: laptops, servers and build runners. An agent that runs entirely inside a vendor’s cloud, such as Copilot Studio or Agentforce, isn’t covered today. A self-hosted one, like n8n on your own Linux server, is covered when the sensor runs on that host.

Yes. Internal or self-hosted AI hosts can be added to what the sensor inspects, and hosts can be excluded.

Oryo is AI EDR: detection and response for AI agents. A sensor on each laptop, rolled out through your MDM, sees every AI agent and the person behind it, checks prompts, skills and tool calls, and can block, warn or log before a request leaves. Each decision is recorded and mapped to AIUC-1, MITRE ATLAS and NIST 800-171.

Discovery tools show you which agents exist, and they’re a good first step. Oryo watches what each agent does on the laptop: it ties every request to a person, checks prompts, skills and tool calls, and can block, warn or log before the request leaves. Use them together.

Free for up to 10 people, with the full product. Beyond that, per person, per month, counting the people who use AI, not agents or tokens. Everything is included.

A pilot on a handful of devices. After an NDA, the sensor installs in minutes and you see your own agents in the first week.

Directly and through partners. MSPs get a multi-tenant console.

Those cover Microsoft’s own stack. Oryo covers any agent on the laptop, Microsoft’s included, and can check your existing Purview policies.

Oryo was founded by security veterans from Okta, Wiz and Proofpoint. The company is Oryo Identity, Inc.