Install Jentic One Beta

Connect the Coro API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Coro API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fcoro.net%2Fcoro" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fcoro.net%2Fcoro" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Coro API.

List managed devices and inspect a single device by ID for OS, posture, and protection status

Retrieve detected threats across the tenant and update an individual threat's status to triage incidents

Create, update, and delete protection policies that govern endpoint behaviour

Fetch a specific policy by ID to audit configuration drift before rollout

List users associated with the Coro tenant and look up an individual user's profile

GET STARTED

Start building with Coro API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Coro API for, with concrete tasks.

★ Automated Threat Triage

Pull the open threat queue from Coro, enrich each entry with device context from the devices endpoint, and update the threat status once the agent or analyst has decided on a disposition. This compresses the manual SOC loop of opening the console, reading the threat, checking the device, and clicking through status changes.

List all threats with status open from GET /threats, for each call GET /devices/{deviceId} to get device posture, then PATCH /threats/{threatId} with the resolved status.

Policy as Code for Endpoint Protection

Manage Coro protection policies from a Git workflow by reading current policy state, diffing against the desired state in a repo, and pushing changes through POST, PUT, and DELETE on the policies endpoints. Lets security teams review policy changes in pull requests instead of dashboard clicks.

Read all current policies via GET /policies, compare with the desired YAML in the repo, and call POST /policies, PUT /policies/{policyId}, or DELETE /policies/{policyId} to converge state.

Device Inventory Sync to a CMDB

Periodically pull every device managed by Coro and reconcile the inventory with an internal asset database or CMDB so that ownership, OS, and protection status stay aligned across systems. Useful for compliance reports and audit trails.

Page through GET /devices, fetch per-device detail via GET /devices/{deviceId} when needed, and upsert each record into the target CMDB.

Agent-Driven Incident Response via Jentic

An AI agent loaded with Coro tools through Jentic responds to security alerts by inspecting the affected device, reviewing the threat detail, applying or tightening a policy, and then marking the threat resolved. The agent reasons over policy state rather than memorising endpoints.

Search Jentic for 'manage Coro security threats', load the threats and policies operations, then chain GET /threats/{threatId}, PUT /policies/{policyId}, and PATCH /threats/{threatId} into a single response.

Key Endpoints

12 endpoints — jentic publishes the only available openapi specification for coro api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/devices

List managed devices

GET

/threats

List detected threats

PATCH

/threats/{threatId}

Update threat status

GET

/policies

List protection policies

POST

/policies

Create a protection policy

PUT

/policies/{policyId}

Update a protection policy

DELETE

/policies/{policyId}

Delete a protection policy

GET

/devices

List managed devices

GET

/threats

List detected threats

PATCH

/threats/{threatId}

Update threat status

GET

/policies

List protection policies

POST

/policies

Create a protection policy

PUT

/policies/{policyId}

Update a protection policy

DELETE

/policies/{policyId}

Delete a protection policy

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring Coro by hand means holding its bearer token and coding the device, threat, and policy calls yourself. Through Jentic you install once, import the Coro API from the API Directory, store the token once, and your agent calls it.

Permission scoping

Coro's threat and policy operations carry the target id in the request, so scope this by operations: allow the agent the calls it needs, such as listing devices and reading threats, and leave writes like updating a threat or deleting a policy out unless you add them. Each operation you credit the agent with stays inside that allowed set.

Credential isolation

Your Coro token is stored once, encrypted, by your own Jentic One instance and injected into the Authorization header at execution time. It never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'list Coro threats' or 'update a Coro policy', and Jentic returns the matching operation with its input and response schemas so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Coro API through Jentic.

Why is there no official OpenAPI spec for Coro API?

Coro does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Coro API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

What authentication does the Coro API use?

The Coro API uses HTTP bearer-token authentication: every request must include an Authorization header of the form Bearer <token>. When called through Jentic, the token is held in your Jentic One instance and injected at execution time so it never enters the agent's prompt context.

Can I update the status of a threat with the Coro API?

Yes. The PATCH /threats/{threatId} endpoint updates the status of an individual threat, which lets you mark threats as resolved, acknowledged, or otherwise progressed once triage is complete.

What are the rate limits for the Coro API?

The OpenAPI spec does not declare explicit rate limits, so production callers should treat 429 responses as authoritative and back off using the Retry-After header where present. Coro's developer portal at developers.coro.net is the canonical place to confirm current limits before high-volume use.

How do I list all managed devices through Jentic?

Search Jentic for 'list Coro devices', load the GET /devices operation, then execute it. Jentic returns the operation schema so the agent knows exactly which query parameters and response fields are available without browsing Coro documentation.

Can I manage protection policies programmatically?

Yes. The /policies endpoints support POST to create, GET to list or read by ID, PUT to update, and DELETE to remove a policy, which together cover the full lifecycle for policy-as-code workflows.

Can I limit what my agent is allowed to do with the Coro API?

Yes. Because you run Jentic One yourself, your own rules decide which Coro operations the agent may call, and each of Coro's operations carries the target id in the request so you can scope access at the operation level. You can allow read-only calls such as GET /devices and GET /threats or GET /policies while leaving writes like PATCH /threats/{threatId}, POST /policies, PUT /policies/{policyId}, and DELETE /policies/{policyId} out of the agent's allowed set. Only the operations you explicitly grant become callable, and the bearer token is injected at execution time so it never reaches the agent's prompt.

Coro API

Name: Coro API
Brand: Coro API
Availability: InStock

Agent-ready OpenAPI document · curated by JenticSecurityThreat Detectionbearer12 EndpointsREST

Know of an official OpenAPI document? Contribute it →

For Agents

Inspect Coro-managed devices, retrieve and update detected threats, and manage protection policies for an organisation. Bearer-token authentication with 12 endpoints under /v1.

Use for: Get the list of devices currently managed by Coro, Find all open threats detected on a specific endpoint, I want to update the status of a Coro threat after triage, List all protection policies configured for my Coro tenant

Not supported: Does not handle network firewalling, SIEM event storage, or vulnerability scanning - use for endpoint protection policy and threat management only.

Jentic publishes the only available OpenAPI specification for Coro API, keeping it validated and agent-ready. The Coro API exposes the Coro cybersecurity platform for programmatic management of endpoint devices, security threats, and protection policies across an organisation. Through 12 endpoints under api.coro.net/v1, it covers device inventory lookups, threat triage and status updates, policy lifecycle management, and user listings. It is designed for security operations teams that want to automate triage, enforce policy from CI, or feed Coro signals into SOAR and SIEM workflows.

Jentic One on Github View OpenAPI Document

Connect the Coro API to your agent

Capabilities

Start building with Coro API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Coro API