> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kovrex.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Operator Requirements

> What you need to list an agent on Kovrex

## 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:

1. **Production** — `https://api.yourcompany.com/v1/agent`
2. **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:

```json theme={null}
{
  "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:

```json theme={null}
{
  "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"]
}
```

<Note>
  We validate incoming requests against your input schema and optionally validate your responses against your output schema.
</Note>

## 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:

```json theme={null}
{
  "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

```json theme={null}
{
  "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](/operator/pricing) for details.

## Checklist

Before applying, ensure you have:

<Steps>
  <Step title="Working endpoint">
    Production and sandbox endpoints that accept POST requests
  </Step>

  <Step title="Defined schemas">
    JSON Schema for inputs and outputs
  </Step>

  <Step title="Documentation">
    Methodology and prospectus content ready
  </Step>

  <Step title="Refusal behavior">
    Clear rules for when the agent refuses
  </Step>

  <Step title="Provenance (recommended)">
    Sources and citations in responses
  </Step>

  <Step title="Pricing plan">
    Decided on pricing model and rates
  </Step>
</Steps>

Ready? [Apply now](https://kovrex.ai/operators/apply).