OdyAgent reads an incident, fetches your yardstick, looks for comparable cases and submits a classification with its reasoning. Under its own identity, traceable at every step. And it never reaches into the open internet: the agent sits in a capsule with no internet access, and the language model runs on infrastructure we operate ourselves, or on yours.
OdyAgent runs in operation and is now opening up to its first organisations. We are looking for a few design partners to be the first to use and shape it.
An agent operating a security management system sees incidents, evidence and weaknesses. What suffices for a writing assistant does not suffice here.
OdyAgent signs in with its own agent identity, claims the task, reports alive while working and completes it. Every step appears in the log under that identity, not a person's.
Every capability carries a manifest of the tools and permissions it requires. Incident classification has four tools and three permissions. Nothing else exists for that agent.
The agent cannot reach OdySecure. Only the orchestrator does, and it is a separate process outside the capsule. Taking over the agent does not give you access to the platform.
Not generating text, but forming a judgement. The sequence is the one a person walks through at first-line triage.
It fetches the incident with everything attached: the report, its origin, the affected asset, the timestamp.
It retrieves the catalogue of severities as it applies in your organisation, not the one it learned somewhere.
It searches similar cases in your history. An alert you have dismissed as noise three times is not news the fourth time.
It submits a classification in a defined shape, with its reasoning. What it does not know for certain, it states as an assumption.
This is the work that in many organisations sits as a pile on a desk each morning and consumes attention all day, even though most of it is routine. Four tools, three permissions, one fixed result format. This work needs no more, and it gets no more.
And what it does not do: decide. Its judgement is a proposal with reasoning, traceable under its own identity. Whether a measure follows is yours.
An agent without a feed is a promise. OdyAgent gets its tasks from the systems already running in your organisation.
Eighteen connectors feed into OdySecure: Wazuh, Zabbix, Graylog, CrowdSec, TheHive and others report alerts, DefectDojo and Dependency-Track deliver vulnerabilities, Greenbone, NetBox and Snipe-IT the asset inventory. Every report becomes an incident in the management system, and every incident can become a task for the agent.
At the other end sits the ticket system: what has been classified can go to Jira or ServiceNow as a work item. Between detection and an assigned task, nobody retypes anything.
Before OdyAgent judges a customer's incidents, it judges ours.
We test the agent on our own infrastructure: against real alerts from live operations, not staged probes. It judges, but it decides nothing. Every judgement is reviewed by hand, on both counts: whether the call is right and whether the reasoning holds.
When a class of alert outside the known ones first appeared, it placed it correctly and stated its assumption explicitly as an assumption rather than a finding.
When the same finding appeared ten times within ninety minutes, all ten were consolidated and pointed at the governing diagnosis. Without a model call. An agent that thinks each alert separately produces ten notifications and ten invoices.
What we count is the stricter measure: a judgement only counts as right for us when the reasoning holds too. We will publish figures once the evaluation is settled and we can evidence where they come from.
Most are built to let an assistant do as much as possible. OdyAgent is built to let it do as little as possible and permit exactly what is needed. What follows describes not a particular competing product but the usual cut.
| Question | The usual cut | OdyAgent |
|---|---|---|
| Prompt injection | Protection lives in the instruction to the model. Text from data and the operator's instruction land in the same context. | A separate service screens incoming content before the agent sees it. It runs locally. What cannot be assessed goes to quarantine rather than through. What comes from data is passed on fenced. |
| Execution environment | The agent runs in the application process or a shared worker. | Its own container per run, without special privileges, with a read-only file system. |
| Network access | An exit to the internet, because tools might need it. | No exit. The agent reaches two proxies on the host and nothing else. |
| Tools | One toolbox for every task, the model picks from it. | A manifest per capability. Incident classification gets four tools and three permissions. Nothing else exists for that run. |
| Access to the business application | The agent holds the credentials and talks to the API itself. | The agent cannot reach the platform. Only the orchestrator does, outside the capsule. |
| Identity and trail | Acts under a service account shared by several operations. | Its own agent identity. Claim, heartbeat and completion each appear in the log. |
| Language model | A vendor endpoint on the network. | Self-operated or yours, through a gateway that routes per tenant, records and limits. |
Every one of these rows is a build decision, not a setting. It cannot be switched off by accident.
None of this is a setting somebody can forget. It is how the thing is built.
OdyAgent uses no model at a hyperscaler. Access runs through a gateway that routes per tenant, records and limits. You can use the model we operate or connect your own. Neither changes the constraints the agent works under.
This is the same principle that governs OdySecure, one level down: where it runs is a decision, not a side effect.
In OdyAgent a capability is not a switch but a contract: tools, permissions, endpoints and the shape of the result.
Incident classification reads an incident, knows the catalogue of severities, searches for comparable cases and submits its classification. Four tools, three permissions, one defined result format. Further capabilities follow the same pattern.
What OdyAgent can do grows with the contracts we write for it. It does not grow by letting a model do more.
A few organisations, real tasks, short paths.
No. It works under its own identity, and every step appears in the log under that identity. Claim, heartbeat and completion are each traceable.
Incoming content passes a local prompt injection screening before processing; whatever it cannot assess goes to quarantine rather than through. Anything originating from data is passed on fenced. The agent can also only call the tools of its capability; an instruction to do something else has no tool that could carry it out.
Yes. The gateway routes per tenant, either to the model we operate or to yours.
It runs in operation, and we are opening it to the first design partners now. It is not yet generally available; that is why there is a programme for it and no price.
OdyAgent works on the data OdySecure already holds: incidents, measures, evidence. It is not a second system but the hand that works inside the first.