Xaidr: In-Process Runtime Security for AI Agents

AI agents are becoming more capable at calling tools, reading data, and taking actions without a human approving every individual step. That flexibility is useful, but it creates a security problem that ordinary application monitoring does not fully solve: what should happen when an agent makes a bad decision, follows a malicious instruction, or reaches beyond the task it was given?

Xaidr is an early open-source attempt to address that problem at runtime. Published by delphisecurity, the project describes itself as security for AI agents that is in-process, has zero dependencies, and uses the Apache 2.0 license. The pitch is not a large security platform or a separate inspection service. It is a small layer intended to sit close to the code executing the agent.

Why runtime location matters

Many security controls live outside an application. Teams may inspect network traffic, place workloads in sandboxes, or review logs after an action has already happened. Those techniques still have a role, but they can be too far away from the agent’s decision-making path to provide immediate control. An in-process design takes a different route: the security logic is embedded in the same execution environment as the agent, where it can potentially observe or restrict activity before the operation completes.

That distinction matters most when an agent can do more than generate text. An assistant that can modify files, call an external API, or access internal records has an action surface that needs boundaries. If a prompt injection or tool error sends the agent in the wrong direction, a control placed inside the runtime may respond earlier than a post-incident audit. Sounds abstract, but it becomes practical when developers need to stop a risky operation rather than merely explain it later.

The tradeoff is equally important. A security component inside the process is close to the behavior it is meant to govern, but it also shares the application’s runtime and failure modes. Teams still need to understand what Xaidr can detect, which actions it can block, and how it behaves when the protected application is under load. “In-process” is an architectural choice, not a guarantee that every agent threat has been solved.

A deliberately small deployment model

Zero dependencies is one of Xaidr’s clearest design choices. Instead of asking a team to operate another service or install a broad software stack, the project aims to keep integration and deployment lightweight. That can be attractive to an independent developer prototyping an agent, or to a security-minded team that wants a narrow control layer without introducing another network hop.

The Apache 2.0 license also makes the project approachable for commercial experimentation. Companies can generally evaluate and incorporate Apache-licensed software under its stated terms, although their legal and security teams should still review the license and the project’s implementation before shipping it. The license removes one common adoption concern; it does not replace documentation, testing, or an internal threat model.

• In-process controls that sit close to agent execution
• Zero-dependency design aimed at simpler integration
• Apache 2.0 licensing suitable for commercial evaluation
• Benchmark and contribution documents included in the repository

For a small team, this combination is pragmatic. A developer can evaluate the project alongside an existing agent instead of designing an entire security service around it. The likely pitfall is assuming that a minimal installation also means minimal configuration. Runtime security is only useful when the team has defined which tools, data sources, and actions are allowed in the first place.

What the repository signals—and what it does not

Repository activity suggests that Xaidr is more than a one-file demonstration. The source information reports 136 commits and points to both BENCHMARKS.md and CONTRIBUTING.md. Those files indicate attention to performance measurement and outside participation, two encouraging signs for a security project that will need both efficient execution and transparent maintenance.

At the same time, the public project remains early. The repository information lists 22 stars, one fork, and a single issue discussion. Those numbers describe initial interest rather than broad adoption, and they should not be read as evidence of production maturity. Public technical detail is also limited in the available information, so readers cannot responsibly infer coverage, latency, supported runtimes, or the completeness of its policy model without inspecting and testing the code directly.

That restraint matters in agent security. A benchmark document can show that performance was considered, but it does not automatically prove that the benchmark matches a real deployment. A contribution guide can make a project easier to improve, but it does not tell teams how quickly security fixes will arrive. Developers evaluating Xaidr should examine its tests, review how failures are handled, and run representative agent tasks rather than relying on repository labels alone.

Who should evaluate Xaidr now?

Xaidr is most relevant to developers building tool-using agents who want to investigate runtime governance without adopting a large external platform. A useful test case would be an internal assistant that can read selected files and call a small set of APIs. The team could define permitted operations, intentionally send confusing or hostile instructions, and observe whether the runtime layer provides the expected controls without disrupting ordinary work.

It is less suitable as an automatic replacement for network isolation, access control, logging, human approval, or sandboxing. Those layers address different failure modes. An in-process mechanism may help an agent stay within policy, while identity systems decide which data it can access and infrastructure controls limit what the process can reach. A sensible evaluation treats Xaidr as one component in defense in depth, not as a complete security boundary.

Before putting it near production workloads, teams should verify three things: what events the project actually observes, what enforcement actions it supports, and how it fails when the runtime or policy layer encounters an unexpected condition. They should also measure overhead using their own tools and prompts. Xaidr’s small footprint makes that kind of hands-on review feasible, which is probably its strongest immediate value.

Xaidr deserves attention as an early, focused experiment in AI agent runtime security. Its in-process and zero-dependency approach is easy to understand, while the limited public traction means expectations should stay modest. For now, it looks best suited to technical evaluation and feedback—not an unexamined production rollout.