OdyAgent, the agentic framework by CybervizeThe analyst your alerts need and you never hired.
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.
What the agent does: the work of an analyst
Not generating text, but forming a judgement. The sequence is the one a person walks through at first-line triage.
- 1
Read the incident
It fetches the incident with everything attached: the report, its origin, the affected asset, the timestamp.
- 2
Fetch the yardstick
It retrieves the catalogue of severities as it applies in your organisation, not the one it learned somewhere.
- 3
Look for comparable cases
It searches similar cases in your history. An alert you have dismissed as noise three times is not news the fourth time.
- 4
Judge and give reasons
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.
There are many agentic frameworks. The difference is in the cut.
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.
The capsule, layer by layer
None of this is a setting somebody can forget. It is how the thing is built.
- Its own container per runNo special privileges, read-only file system.
- A network with no way outThe agent cannot reach the internet. Its only counterpart is two proxies on the host.
- Two paths, no moreOne to the platform API, one to the language model. Both log, both limit.
- Prompt injection screeningA separate service screens incoming content before the agent sees it. It runs locally, not at a vendor. What cannot be assessed goes to quarantine rather than through.
- Content fencedWhat comes from data is treated as data, not as an instruction.
- Only two doors outwardPublicly reachable are the task webhook and a health check. Nothing else.
What a design partner gets, and what we need in return
A few organisations, real tasks, short paths.
You get
- Access to OdyAgent ahead of general availability
- The first capability on your incidents, set up together
- A direct line to engineering, without a ticket queue
- A say in which capability comes next
We need
- A running OdySecure with real incidents
- A named person who judges the results
- A willingness to let us hear what does not work
For your whole company: sovereign AI
On the same principles we offer an AI assistant for all staff. It runs on hardware inside your network, no request goes to a model vendor, and usage is documented through OdyControl. You test it for three days with your own documents before you decide.
Why an agent here has to be built differently
An agent operating a security management system sees incidents, evidence and weaknesses. What suffices for a writing assistant does not suffice here.
It replaces a user, so it needs that user's trail
OdyAgent signs in with its own agent identity, claims the task, reports alive while working and completes it. The steps appear in the log under that identity, not a person's.
It gets only the tools its task needs
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.
It never talks to the platform itself
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.
Where the work comes from
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. Alerts become an incident in the management system if they are above the configured threshold and no rule excludes them; vulnerabilities and asset data flow into their own inventories. An 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.
We run it against ourselves first
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.
Including what it had never seen
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.
Ten alerts, one diagnosis
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.
Where the model runs is a decision
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.
The first capability: classifying incidents
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.
Frequently asked questions
Can the agent change something without anyone seeing it?
No. It works under its own identity, and the steps appear in the log under that identity. Claim, heartbeat and completion are each traceable.
What happens if someone tries to steer the agent through an incident text?
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.
Can we use our own language model?
Yes. The gateway routes per tenant, either to the model we operate or to yours.
Is OdyAgent already in use?
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.
Part of the platform
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.