CARBON — Engineering ConfidenceUser Guide
CHAPTER 21 / 60 Pro

/carbon-security

Run focused CARBON Security testing and generate a branded security report.

Sharon · SecuritySecurity & resilience

When to use it

You need a scoped review of application trust boundaries.

Before you start

Identify authorized targets, roles and synthetic accounts. Trace authorization on the server, not just hidden UI controls. Static suspicions require safe reproduction before a runtime exploit is claimed.

Try this in your coding agent.

/carbon-security Review src/auth for session and authorization weaknesses; stay read-only.

Replace sample paths with your project. Slash names are shorthand; your host may use a plugin prefix or a skill picker. Invocation help →

ILLUSTRATIVE WALKTHROUGH

Authorization boundary

An expanded teaching example, not a recorded or live execution. The report stays visible while the replay explains how to read it.

  1. 01Read context
  2. 02Investigate
  3. 03Show evidence
  4. 04Report

Coding-agent conversation

Read context

I’m reviewing authorization boundary. I’ll keep the scope and permissions explicit.

Investigate

Follow the weakest evidence link and record what remains blocked.

Show evidence

Here is the evidence trail to inspect: Read-only source trace: request accountId → order lookup without visible ownership check.

Report

The server route appears to trust a client-supplied account identifier. A suspected vulnerability needs authorized reproduction; no exploit is run here.

CARBON

Example report

Illustration
Inspect the identity boundary
Inspect the identity boundary — TestBucks teaching screen

TestBucks course screen with illustrative analysis. The screenshot supplies context; the demo does not establish a newly observed bug.

  1. User action
  2. Identity / validation
  3. Allowed outcome

Illustrated outcome

The server route appears to trust a client-supplied account identifier.

Evidence to inspect

Read-only source trace: request accountId → order lookup without visible ownership check.

Still untested / not established

A suspected vulnerability needs authorized reproduction; no exploit is run here.

Ready. Read the full example or play its steps.

What a useful result contains

A bounded claim

For authorization boundary, state the target, revision, environment and actual work performed. Keep planned, executed, blocked and untested work separate.

An inspectable trail

Read-only source trace: request accountId → order lookup without visible ownership check. In a real run, retain the source, trace, screenshot or fixture behind the conclusion.

The qualification

A suspected vulnerability needs authorized reproduction; no exploit is run here.

The next decision

Decide whether the evidence calls for a focused check, a reviewed fix or more context. Do not convert a plausible example into a verified finding.

Adapt the example to your project

  1. Replace authorization boundary with a real feature, path or decision in your project.
  2. State the expected rule and its source. Include safe fixtures, constraints and a budget where appropriate.
  3. Ask for exact evidence and remaining gaps. Approve consequential actions separately.
/jay Review the /carbon-security result. Separate observed evidence, assumptions and untested scope, then recommend the next useful check.

Where to go next

/carbon-api →/carbon-test →

Content checked against the local command definition: skills/carbon-security/SKILL.md. Examples adapted from the homepage’s TestBucks walkthroughs. Availability is edition- and host-dependent.