PREVIEWCISO360AI is offered as-is while in preview. Features and data may change. Learn more.
All posts

Bring your own agent — running an AI assistant against your security programme safely

What it takes to let Claude, Copilot or Cursor work directly against your compliance and exposure data without handing it the keys — project scoping, approval gates and an audit trail.

CISO360AI

The interesting question about AI agents in security is no longer "can it summarise my findings". It is: what happens the first time an agent decides to change something?

Our answer is a native Model Context Protocol server. You point your own agent — Claude, GitHub Copilot, Cursor, or anything that speaks MCP — at your tenant, and it works against your real data. On every plan, including Free. The design work is not in the connection; it is in everything that constrains it.

Connecting

The endpoint is streamable HTTP:

{
  "type": "http",
  "url": "https://api.ciso360.ai/mcp",
  "headers": { "Authorization": "Bearer csk_..." }
}

Two ways to authenticate. A scoped API key issued in Settings → API Keys, bound to one organisation, is the direct route. Or OAuth 2.1 with Dynamic Client Registration, which is what you get if you add the connector from the Claude connector directory — you sign in, approve the request, and no key is ever copied and pasted. Either way your organisation is derived from the credential, not from something the agent asserts.

The tool list is discoverable at runtime through the MCP tools/list method, and the full reference with JSON schemas lives in the API index.

Three constraints that make it safe

Reads span the organisation; writes do not. Read tools return results across every project you can access, each result tagged with the project it came from — so one agent can reason about a whole multi-project programme in a single pass. Write tools require an explicit project id. There is no such thing as a silent cross-project write.

Higher-risk actions stop and ask. Anything destructive, and anything that accepts risk, is proposed rather than performed: it lands in the app as a proposal for a human to approve or reject. Lower-risk triage — marking a finding a false positive, or suppressing it with a reason and an optional expiry — runs autonomously, and is recorded in the audit log either way. Agent keys are deny-by-default and can never run a destructive tool at all.

Everything is written down. Every tool call that changes state produces a typed audit event with the credential, the project and the reasoning. When someone asks in six months why a risk was accepted, the answer is a record, not a recollection.

What people actually use it for

The pattern that keeps recurring is not "do my compliance for me". It is closing the gap between two systems that never talked:

  • "Which of our claimed controls does our own scan data contradict?" — an agent can hold the control states and the findings in the same context, which no human dashboard does.
  • "Draft the remediation plan for every gap in the NIST CSF Protect function, ordered by exposure." — proposed, reviewed, approved.
  • "What changed in our posture this month, and what should the board hear about?" — the same question the executive report answers, asked conversationally.

For managed service providers and virtual CISOs the multi-project shape matters most: one scoped key per client organisation, project sharing for third-party assessments, and an agent that can run the whole book of work without ever crossing a tenant boundary.

Where to start

Connect it in read-only mode first and ask it what it can see. Nothing it does can surprise you until you approve something.

Connect your agent →