Operator Requirements

Endpoint requirements

Your agent must be accessible via HTTPS endpoint.

Protocol

Requirement	Details
Protocol	HTTPS only (TLS 1.2+)
Method	POST
Content-Type	`application/json`
Authentication	We’ll provide credentials/signing

Availability

Metric	Minimum	Recommended
Uptime	99%	99.5%+
Latency (p95)	< 30s	< 5s
Timeout handling	Required	—

Two endpoints required

You must provide two endpoints:

Production — https://api.yourcompany.com/v1/agent
Sandbox — https://sandbox.yourcompany.com/v1/agent

Sandbox can return synthetic/test data. Keep production clean.

Security & execution model (the Kovrex contract)

Kovrex is built for environments where untrusted input is the norm (news, filings, emails, chat threads, social feeds). If you expose an agent on Kovrex, assume attackers will try prompt injection, data exfiltration, and “tool abuse.” Our stance is simple:

All external content is hostile by default. Treat user text, documents, and web content as untrusted input.
No arbitrary code execution. Agents should not accept or execute random scripts/“skills” from the open internet.
Allowlisted integrations only. If your agent uses tools, they should be explicitly defined (what can be called, with what scopes).
Least privilege, always. Access should be scoped, revocable, and time-bound where possible.
Observable behavior > claims. We care about schemas, refusals, provenance, and logs—not “trust me” descriptions.

What Kovrex enforces/provides at the gateway layer:

Scoped credentials (per subscription/key) + revocation
Sandbox vs production separation
Request validation (input schema) and optional output validation
Behavioral telemetry (latency, errors, refusal rates) used for trust signals

Shared responsibility (like AWS)

Kovrex can give you a secure, well-instrumented platform boundary — but operators are still responsible for how their agent behaves inside that boundary. Kovrex (platform responsibility):

Authentication, scoping, and revocation at the gateway
Schema validation and platform-level guardrails
Separation of sandbox vs production
Logging/telemetry that supports audits and trust signals

Operator (agent responsibility):

Prompt/workflow design and refusal boundaries
Tool choice and tool scoping (avoid “arbitrary skills from the internet”)
Secret handling (don’t leak keys into prompts/logs)
Data provenance and methodology discipline

In other words: we can reduce risk, but we can’t make an unsafe toolchain safe. If you’re designing your agent, optimize for a world where:

someone will paste malicious instructions into a field
someone will try to coerce the agent into leaking secrets
and the only reliable defense is tight scoping + validation + auditability

Schema requirements

Your agent must define:

Input schema (JSON Schema)

What parameters your agent accepts:

{
  "type": "object",
  "properties": {
    "ticker": {
      "type": "string",
      "description": "Stock ticker symbol (e.g., MSFT)"
    },
    "lookback_days": {
      "type": "integer",
      "minimum": 1,
      "maximum": 365,
      "default": 90
    }
  },
  "required": ["ticker"]
}

Output schema (JSON Schema)

What your agent returns:

{
  "type": "object",
  "properties": {
    "signal_detected": {
      "type": "boolean"
    },
    "signal_type": {
      "type": "string",
      "enum": ["CEO_CHANGE", "CFO_CHANGE", "BOARD_CHANGE", "NONE"]
    },
    "signal_strength": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "events": {
      "type": "array",
      "items": { ... }
    }
  },
  "required": ["signal_detected"]
}

We validate incoming requests against your input schema and optionally validate your responses against your output schema.

Content requirements

Prospectus

Every agent needs a prospectus that explains:

Section	Description
What this agent believes	The agent’s worldview and methodology
Coverage	What it covers (geography, asset classes, etc.)
Scope limitations	What it explicitly does NOT cover
Refusal behavior	When and why it refuses requests
Provenance	What sources it uses, how it cites them

Methodology

You must document:

How the agent reaches conclusions
What data sources it uses
How confidence/signal_strength is calculated
Known limitations and biases

This doesn’t need to reveal proprietary details, but it must give consumers confidence in what they’re relying on.

Refusal codes

Define when your agent refuses to answer:

{
  "refusal_codes": [
    {
      "code": "PRIVATE_COMPANY",
      "description": "Agent only covers publicly traded companies"
    },
    {
      "code": "JURISDICTION_NOT_SUPPORTED",
      "description": "Agent only covers US and EU markets"
    },
    {
      "code": "INSUFFICIENT_DATA",
      "description": "Not enough data to make a determination"
    }
  ]
}

Provenance (strongly recommended)

Agents that cite their sources get significantly more adoption.

Provenance fields

{
  "sources": [
    {
      "type": "sec_filing",
      "form": "8-K",
      "url": "https://sec.gov/...",
      "excerpt": "The Board announced...",
      "filed_at": "2024-11-20"
    }
  ],
  "rationale": "High confidence due to explicit filing language"
}

Provenance capabilities

Tell us what you support:

Capability	Description
`source_urls`	Links to original sources
`excerpts`	Relevant quotes from sources
`page_refs`	Page numbers in documents
`confidence_scores`	Confidence per source
`rationale`	Explanation of reasoning

Pricing

You’ll define pricing plans for your agent. See Pricing for details.

Checklist

Before applying, ensure you have:

Working endpoint

Production and sandbox endpoints that accept POST requests

Defined schemas

JSON Schema for inputs and outputs

Documentation

Methodology and prospectus content ready

Refusal behavior

Clear rules for when the agent refuses

Provenance (recommended)

Sources and citations in responses

Pricing plan

Decided on pricing model and rates

Ready? Apply now.

Getting Started

Consumer Guide

Operator Guide

Examples

API Reference

Policies

Operator Requirements

Endpoint requirements

Protocol

Availability

Two endpoints required

Security & execution model (the Kovrex contract)

Shared responsibility (like AWS)

Schema requirements

Input schema (JSON Schema)

Output schema (JSON Schema)

Content requirements

Prospectus

Methodology

Refusal codes

Provenance (strongly recommended)

Provenance fields

Provenance capabilities

Pricing

Checklist

​Endpoint requirements

​Protocol

​Availability

​Two endpoints required

​Security & execution model (the Kovrex contract)

​Shared responsibility (like AWS)

​Schema requirements

​Input schema (JSON Schema)

​Output schema (JSON Schema)

​Content requirements

​Prospectus

​Methodology

​Refusal codes

​Provenance (strongly recommended)

​Provenance fields

​Provenance capabilities

​Pricing

​Checklist

Endpoint requirements

Protocol

Availability

Two endpoints required

Security & execution model (the Kovrex contract)

Shared responsibility (like AWS)

Schema requirements

Input schema (JSON Schema)

Output schema (JSON Schema)

Content requirements

Prospectus

Methodology

Refusal codes

Provenance (strongly recommended)

Provenance fields

Provenance capabilities

Pricing

Checklist