VirQaraUnder development
In development

AI Badge

Agents write the fix. You set the limits.

An AI writes a tool as one Quaryn file. Its header declares the capability families it uses. Approve a tool's authority once and it is enforced on every run, instead of reviewing every change the agent proposes. The runner is built and systematically tested with documented boundaries. The host for approvals, outbound actions, and signed receipts is designed and not built.

report_writer.qry
uses [fs]

fn tool(input: Input) -> Output {
    write_file(path, text)
}
The header declares file access. Quaryn checks every reachable helper. The sandbox narrows what the process can see.

From tool proposal to signed receipt

The runner is built. The approval and action workflow below is the host design.

  1. 1

    The agent proposes a tool

    One Quaryn file contains the description, capability header, entry function, and tests. The runner checks formatting, compiles under the displayed capability grant, and runs the tests inside the sandbox.

  2. 2

    A person approves its authority

    The planned approval view shows the capability families, permitted operations, destinations, and resource ceilings. It also shows how the proposed version compares with the version it replaces.

  3. 3

    The runner enforces execution limits

    Quaryn rejects undeclared or withheld capability use before execution. A sandbox narrows the process view. Kernel ceilings, a hard timeout, and output limits bound the run.

  4. 4

    The host checks the requested action

    In the planned workflow the tool returns an action request. The host checks it against the approved policy, supplies the credential, and contacts the approved destination.

  5. 5

    The host records the result

    The host design calls for a signed receipt linking the finding, tool version, requested action, outcome, and execution record. Verified remediation requires a later successful scan that covers the relevant finding and the expected revision or resource state.

What AI Badge is being built to do

  • The compiler rejects capability use beyond the tool's declaration or the runner's grant.
  • The runner adds a sandbox, resource ceilings, a hard timeout, and an output limit.
  • The host design keeps outbound credentials with the host and limits actions to approved operations and destinations.
  • An approved policy may cover a new tool version only when the host can establish that the version stays within it. Wider authority requires fresh approval.
  • Signed receipts are part of the host design. They record requested actions, outcomes, and how execution ended.

The aim is fewer repeated approval decisions within a policy you have already approved. Whether a fix worked still needs evidence.

Talk to us Back to VirQara

Where this stands

Neither product line is generally available yet. Nothing on this site is for sale today.

The Detection Licensing Auditor engine exists. Its service is not built. The AI Badge runner is built and systematically tested with documented boundaries. Its approval, action, and receipt host is designed and not built.

If you evaluate detection content, or use agents to act on findings, we would like to hear how you work.

contact@edgexene.io

The report is an engineering analysis of license text and evidence. It is not legal advice and does not substitute for counsel.