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