Limitations
Read this as a compliance statement, not a footnote. If your control narrative depends on something below, you need a different tool for that part.
It cannot read your code
No filesystem, no repository access, no upload endpoint. There is no tool that accepts file content.
This is the privacy guarantee, not a gap. The alternative would be shipping your source to a third party to be scanned.
Instead: the 16 local prompts drive the Vulnetix CLI on your machine.
It cannot apply a fix
It will tell you the exact manifest edit, the install command, the verification command and the rollback. It cannot make the change.
Instead: vulnetix_fix_plan produces the plan; your agent applies it, or the
vulnetix_fix prompt walks the CLI through it with backup and rollback.
It cannot run a scanner
No Semgrep, Trivy, Grype, Syft or cosign. No sandbox and no code execution.
Instead: the CLI has its own scanners and composes with those tools when present locally.
It cannot execute an exploit check
vulnetix_exploit_test generates a command. It never runs one, against anything.
This is by design and permanent. Running an exploit check against infrastructure you do not own is likely a criminal offence in most jurisdictions, and no server should make that a one-click action.
It has no memory
Stateless by protocol design. It does not remember what you asked, what you decided, or what you triaged last week.
Instead: .vulnetix/memory.yaml in your repository, written by the CLI and
read by the vulnetix_dashboard prompt. Durable per-organisation state (triage
decisions, VEX) lives in the Vulnetix API.
It cannot connect over OAuth
Authentication is an API key in a header. A client that supports only OAuth cannot connect today.
The RFC 9728 metadata document is published with an empty authorization_servers
list so an authorization server can be added later without breaking anything
already configured. That work is not done.
Affects: hosted connector platforms that disallow user-supplied headers. Does not affect: every locally-run client on this site.
Some data is plan-gated
Exploit records, IOC records, sighting events and threat-actor attribution need Pro. Counts are returned on every tier, and every gated tool says so explicitly in its response.
An empty list never silently means “none exist.”
The AI layer can be wrong
vulnetix_triage_reason, vulnetix_secure_code_write,
vulnetix_detection_rules, vulnetix_exploit_test and vulnetix_fix_plan add a
model-written section. It is labelled as derived, and it is interpretation.
Verify anything you act on. The database half of every one of those results is deterministic and is the part to trust.
It is not a merge gate
An agent can be asked for a pass/fail verdict, and it can be wrong in both directions.
Instead: for a deterministic gate use the CLI, which exits non-zero itself with no model in the path:
vulnetix scan --evaluate-sca --severity high --exploits weaponized
Coverage is the database’s coverage
Aggregating 150+ sources is not the same as omniscience. A vulnerability nobody has published is not in it, and a package no source tracks has no history here.
_meta reports what was consulted. Absence of evidence is not evidence
of absence, and the tools do not pretend otherwise.
Rate limits are real
Quota is per organisation on a rolling 24-hour window. An agent in a loop can
exhaust a day’s budget in minutes. _meta["vulnetix/rateLimit"].remaining is on
every result, and a well-behaved agent reads it.
Things not built yet
- OAuth authorization server
- The Tasks extension (needs durable state, which the server does not have)
- Streaming reduction for very large Pro-tier exploit enumerations
- Webhooks or subscriptions
Issues and requests are read.