Book a walkthrough
ColossalX
Sign inBook a walkthrough

ProveCode securityx, held

Code security, from the repository to the running app.

Secrets, dependencies, insecure code and model files checked on each push, with findings that become tickets and a gate in your pipeline.

How it works

Specs

Code security, in detail

Delivery and data

Delivery
SaaS, from one login.
Isolation
Each customer runs in an isolated workspace with its own database.
Certifications
None held. Frameworks are mapped to and assessed against.

Frameworks

OWASP LLM Top 10 (2025)
Covered in probes and scans: LLM risks in code scans.
OWASP MCP Top 10
Covered in probes and scans: MCP client configuration checks.
OWASP Top 10 for Agentic Applications
Assessed per agent against: Scored by the CI/CD gate.
See the frameworks

Last reviewed 6 Oct 2026

From a push to a decisionIllustrative

From a push to a decision: payments-service to one scan; one scan found calling refunds-agent; one scan to ticket (finding); one scan refused before CI gate (build failed).

In short

Code security in ColossalX scans your repositories for leaked secrets, exploitable dependencies, insecure code and exposed personal data, checks MCP client configuration and inspects model files without running them. Findings become tickets, incidents and risk entries, live app scans test running apps and AI endpoints, and a CI/CD gate decides before an agent ships.

A developer commits a live payment key, and the agent that uses it ships that afternoon.

ColossalX finds the key on push, confirms it still works, and the CI gate fails the build.

How it works

From a leaked key on push to a failed build.

A live payment key lands in a repository. It is found on push, confirmed live, held at the gate and ticketed to an owner.

Workflow · a leaked key, held at the gateIllustrative

01 Push scanned

A push to payments-service starts a scan of what changed.

02 Confirmed live

A read-only check confirms the key still works; it is never suppressed.

03 Gate holds

The CI gate fails the deploy of the agent that uses it.

04 Ticketed to owner

A ticket with an owner, closed only by a clean rescan.

What you see

What changed since the last scan, and what it found.

Security alerts when a re-scan surfaces new critical or high findings, and totals for secrets, known vulnerabilities and code issues across the repositories you connect.

  1. Scan on push
  2. Four kinds of finding
  3. False positives teach
  4. Gate the pipeline
Read the detail, step by step4
  1. Scan on push. Repositories are scanned when added, on each push and on new commits. One Git report covers repositories from 8 source-control providers. A deep scan reads far more files and expands each dependency's own dependencies, and says what it read, what was empty and what it could not reach. Source is read in memory; findings are kept, with secrets redacted.
  2. Four kinds of finding. Secrets, exploitable dependencies, insecure code and exposed personal data, in one result. Dependencies carry known-exploited and exploit-likelihood signals and the fixed version. MCP client configuration is checked, and model and dataset files are inspected without ever being loaded. Triage runs on your own configured model and names the model that answered.
  3. False positives teach. Reject a finding with a reason, and the scanner learns from it. A rejection can apply to one value, a pattern in one folder, or test code across the workspace. Live secrets and known-exploited dependencies are never suppressed automatically, and a rejection is flagged, never deleted.
  4. Gate the pipeline. A CI/CD gate with templates for 6 CI systems, returning SARIF. The gate runs an OWASP Agentic assessment, checks the guardrail profile, can run a code scan and authorisation probes, and returns passed, failed or requires approval. Live app scans test running apps, APIs and AI endpoints and gate only on newly introduced problems.
Repository scanIllustrative

An illustrative repository scan: a push to a payments service scanned, two findings new since the last scan, a leaked API key confirmed still live and an exploited dependency, the CI gate failing the build, an older finding left in the baseline, and a ticket raised for the owning team.

How it connectsx, held

Where a finding in code goes next.

A finding in code reaches the people and records that act on it.

  1. The AI-BOM

    AI libraries found in code are listed apart, with approved baselines and drift alerts.

  2. The agent registry

    Agents found in code are registered with a threat brief built from their own code.

  3. Threat intelligence

    A threatened AI library raises an update advisory on the exact agent built from it.

  4. Owned work

    Findings become tickets in the tool that will close them, and close on a clean rescan.

Honest by design

What it does, and what it does not.

Scan scope · stated plainlyIllustrative

Scan scope · stated plainly: Source code Read in memory; Findings Kept, secrets redacted; Model files Inspected, never run; Deep scan Says what it could not reach; Live app scans Active tiers on proven domains. Read, never run.

What it does not do

x, not measured

Self-managed Git servers are not yet proven; only the GitHub Actions template has run in real CI.

All 4 limits
  • Code analysis does not trace data across a whole program; dependency analysis is the deeper check.
  • Findings keep a short excerpt with secrets redacted; your source itself is not stored.
  • Active, API and AI endpoint scans need a domain you have proven you own.

How we know

  • Live secrets and known-exploited dependencies are never suppressed automatically.
  • A deep scan says what it read, what was empty and what it could not reach.
  • Model files are inspected, never executed: ColossalX runs no customer code.
  • Triage names the model that actually answered, on your own configuration.

Questions

Questions buyers ask

What is AI application security?

AI application security protects the software that builds and runs AI: the code, the AI libraries and agent frameworks it imports, model files, configuration such as MCP client settings, and the pipeline that ships it. ColossalX scans repositories, inspects model files, tests running apps and AI endpoints, and gates the pipeline before an agent ships.

Can ColossalX scan ML model files safely?

Yes. Model and dataset files, such as pickles and PyTorch weights, are inspected without ever being loaded, so code hidden in a serialised model is read rather than run. A critical or high finding returns blocked, can quarantine the agent that owns the file and records an incident. ColossalX executes no customer code anywhere.

Which source-control and CI systems are supported?

One Git report spans 8 source-control providers, and the gate ships templates for 6 CI systems. Proof differs by system: the GitHub Actions template has run in a real CI system, while self-managed source servers and the other templates are built and checked against the gate but not yet proven in a customer environment.

What is a CI/CD security gate?

A CI/CD security gate is a step in the pipeline that can stop a deployment. The ColossalX gate runs an OWASP Agentic assessment, checks the guardrail profile, can run a code scan and authorisation probes, returns passed, failed or requires approval, and writes SARIF into the CI system's own code-scanning view.

How are false positives handled?

You reject a finding with a reason, and the scanner learns: the same value anywhere, a pattern in one folder, or test code across the workspace. Live secrets and known-exploited dependencies are never suppressed automatically, and a rejection is flagged and kept, never deleted, so an auditor can see what was set aside.

Related

Where to look next.

Next step

Know your x, held.

See a scan of your own repository: what it found, what it could not reach, and what the gate decided.

Book a walkthrough Email us instead
  1. 01Tell us what you run
  2. 02See the four verbs on it
  3. 03Decide where to start