MCP and connector references

Overview

• An integration is a configured source (for example your Anthropic account). Each has a connector that runs discovery through an adapter.
• Adapters run in mock mode (fictional data, for evaluation) or live mode (calls the provider's API with a credential you reference).
• Discovery never writes: adapters list and read, and change nothing in the source system.
• Results are reconciled into the registry: new agents, models, MCP servers, tools, resources, identities and permissions are added; risk scores and the Agent Security Graph are recalculated afterwards.

Connector catalogue

Every adapter is available in mock mode. Live modes have the status shown.

Agents built on other platforms can be registered in the portal, through the API, or with a manifest in GitHub. The integrations planned next are listed on the platform page.

Running discovery

1. Create an integration: Integrations → Add integration (kind, name, mode, an optional credential reference and non-secret JSON configuration).
2. Choose Run discovery. Runs are manual in this release. You can pass an idempotency_key through the API so a retried request returns the original run.
3. Each run records its status (running, then succeeded or failed), counters (agents, models, MCP servers, tools, resources and identities added; tools changed; findings opened), warnings and any error. Runs are audited.

How results are reconciled

Discovery never deletes records. Items that disappear from a source stay in the registry until you remove or contain them.

Credentials

• Live adapters use a credential reference: a pointer to a secret in your secret store (provider and path), never the secret itself. Integration configuration rejects keys such as secret, password, api_key, token and client_secret.
• The secret is resolved at run time and sent to the provider's own endpoint and nowhere else. It is never stored or returned by CydraLabs.
• Credential references can be revoked or rotated as a containment action.
• Outbound requests from live adapters are checked against SSRF rules: loopback, private, link-local and cloud metadata addresses are refused.

MCP discovery

The MCP connector reads one server over the streamable HTTP transport:

1. initialize (protocol version 2025-06-18, client cydra-discovery), keeping the Mcp-Session-Id the server returns.
2. notifications/initialized, then tools/list. JSON and server-sent-event responses are accepted (up to 2 MB); redirects are not followed.
3. Each tool becomes <tool_prefix>.<tool name> with its title, description and input schema.

CydraLabs assigns each tool a privilege class (read, write, destructive, financial or admin) from its name and description, independently of what the server claims. A server's readOnlyHint annotation is recorded: if the server declares a tool as not modifying anything while CydraLabs classifies it as able to change something, a high severity tool poisoning finding is opened. Security teams can reclassify any tool.

MCP trust states

• "Privileged" means write, destructive, financial or admin. Baseline rule POL-006 denies those calls with UNTRUSTED_MCP_PRIVILEGED_TOOL; read tools stay available. To stop a specific tool entirely, block it.
• Changing a trust state (PATCH /api/v1/mcp-servers/{id} with a reason) needs the inventory:control permission and is written to the audit log and the evidence chain.
• If a later discovery finds that an approved server's tools changed (a different capability hash), the server returns to unknown and a finding is opened, so changed tools are reviewed before privileged use.
• In the Agent Security Graph, servers appear as mcp_server nodes linked to the tools they expose and the agents that use them; unknown, unsigned and quarantined servers are highlighted on high-risk paths.

MCP mediation

Agents send each proposed MCP tool call to CydraGateway as an action, before calling the tool. The gateway resolves the tool and its MCP server, adds tool.target_type = "mcp_tool" and the server's tool.mcp_trust_state to the decision input, and applies the same ten-step decision as any other action: policy, inspection, approval and evidence. See the architecture and policy language.

POST /api/v1/actions
Authorization: Bearer <agent workload token>
Idempotency-Key: crm-update-7f3c

{
  "tool": "hr-records.employees.update",
  "operation": "invoke",
  "target": "hr://employees/E-1042",
  "parameters": {"employee_id": "E-1042", "department": "Finance"},
  "justification": "Transfer approved by HR ticket HR-5521"
}

GitHub agent manifest

The GitHub connector reads .cydra/agent.json from each repository. One manifest describes one agent:

{
  "name": "Code Review Agent",
  "description": "Reviews pull requests and suggests changes",
  "purpose": "Developer productivity",
  "framework": "langgraph",
  "environment": "production",
  "owner": {"name": "Sam Rivera", "email": "sam.rivera@example.com"},
  "tools": ["github.pull_requests.read", "github.comments.create"]
}

Tool keys listed in the manifest become permissions for the agent when the tools exist in your inventory (for example from the MCP connector).

Connector contract

Adapters implement one small interface, which keeps model, identity and developer platforms interchangeable. Pilot customers can add adapters for their own systems with CydraLabs.

class ConnectorAdapter(Protocol):
    key: str    # e.g. "mcp" or "mock.mcp"
    kind: str   # openai | anthropic | mcp | entra_id | github
    mode: str   # "live" or "mock"

    def discover(self, config: dict[str, Any], secret: str | None) -> DiscoveryResult: ...

Adapters raise a connector error for expected failures (for example a missing credential); the run is then recorded as failed with the message.

Endpoints

All paths are under /api/v1. Full request and response details are in the API reference.

Applies to the CydraLabs proof-of-concept platform. Last updated 4 October 2026. Questions or corrections: contact us.