What is AI-agent security?
AI-agent security is the practice of governing the AI agents, MCP servers, agent skills, and local models running inside your organisation, knowing which exist on which hosts, what each one can reach (filesystem, credentials, shell, network egress), and what to do when one of them turns out to be malicious. It is distinct from model safety, which concerns what a model says, and from application security, which concerns the code you write. Sekeye is the layer built around the agents themselves.
What is MCP governance?
MCP governance is knowing every Model Context Protocol server installed across your fleet, what capabilities each one holds, and whether it should be there. An MCP server is a plugin that grants an AI agent tools and data access; it installs from a config file, updates without review, and inherits whatever credentials sit in the agent's environment. Governance means inventory, blast radius, and, on the Sekeye roadmap, an allow-and-deny gate before install.
Is Sekeye an EDR?
No, and it will not become one. Your EDR watches the operating system. Sekeye watches the AI agents running on top of it: what each one is, and its blast radius. Watching what an agent does is the Catch phase on our roadmap, and even then we plan to read the logs agents already write rather than hook the kernel. The syscall layer stays your EDR's job. We run alongside it.
What does Sekeye do today, and what is still roadmap?
Shipping today: discovery of every AI agent, MCP server, skill, and local model plus the classic package, extension, and OS-package surfaces on laptops and servers; a blast-radius profile per agent; prioritisation against live threat intel including AI-infrastructure CVE and CISA KEV; and remediation with ordered credential-rotation playbooks. Roadmap, clearly staged: Govern, deciding what an agent is allowed to do, is next, and Catch, finding out when one turns, follows. The Drig agent is read-only today: it does not block, quarantine, or kill anything.
What does Sekeye deliberately not do?
Runtime behavioural analysis and process blocking, that's the EDR layer we coexist with, not replace. We're also not a log lake: we surface findings rather than warehousing your activity stream. No TLS interception or browser DLP (integrate your CASB instead), no kernel-level syscall monitoring (we read what your existing sensors already produce), and no code-level analysis or sandboxing of marketplace software. Each of these is either covered elsewhere in your stack or honestly not our surface.
Is there an agentless mode?
No, and that's deliberate. The on-host agent is what makes self-hosted, air-gapped, and offline-buffered deployment work, the things an agentless collector fundamentally cannot do. It's a single read-only Go binary with no listening ports, and it's the reason the data never has to leave your perimeter.
What does Sekeye never collect?
File contents beyond manifests and configs, environment variable values (we take the names of MCP environment variables, never the values), browser history, credentials, and keystrokes. The ingest schema rejects any record carrying an environment value, and the agent hard-denies credential stores at the filesystem layer. These are permanent product commitments, not MVP simplifications.
Can we self-host Sekeye?
Yes, and it is worth separating the two halves. The console is one deployment you run on your own infrastructure, air-gap capable behind an offline licence. The agent is what lands on each endpoint: signed installers for Mac, Linux and Windows, pushed with whatever you already use to manage laptops and servers. One console, every endpoint. Fleet size changes how you size the console, not how you deploy it. Same binaries as our SaaS, never a fork. Self-hosting matters here because agent inventory reveals which teams run which AI tooling, and plenty of buyers will not send that off-premises.
What about the gap between scheduled scans?
We own it. Sekeye is the posture and governance layer, not a runtime monitor. Install-triggered scans narrow the window on the host, and retro-match re-runs matching across current inventory server-side whenever the catalog updates, no rescan needed, so a newly published malicious MCP lights up existing fleet state within the four-hour catalog freshness target. Continuous behavioural watch arrives with the Catch phase on the roadmap.
How is Sekeye different from Wiz AI-SPM, CrowdStrike Shadow AI Discovery, or Koi?
Those products discover AI usage from the cloud side and are priced and packaged for large enterprises. Sekeye lives on the host where the agent actually runs, laptops and servers alike, goes deep on MCP servers, agent skills, local models, and user-level package managers, self-hosts or air-gaps, and is priced per host for mid-market fleets. MCP gateways govern the traffic you route through them; Sekeye covers the agents installed everywhere else.
What OS support ships today?
Drig is a single Go binary cross-compiled for macOS, Linux, and Windows on amd64 and arm64. Measured performance numbers today are Linux-side; the macOS and Windows compile paths exist and pass CI but have not been benchmarked, and those numbers land alongside the hardening pass.
What can auditors get out of Sekeye?
Sekeye produces the AI-agent and MCP inventory, exposure, and incident-response evidence that CERT-In, DPDP, SEBI CSCRF, NIS2, and DORA ask for, inside your data-residency perimeter. Format details are being validated with design partners. Compliance itself stays your team's job, Sekeye produces the artefacts, you file the story.