Attach a rule file to a role
roles:
engineer:
guardrails:
- guardrails/safety.yaml
- guardrails/conventions.yaml
Governed autonomy
MARS does not treat autonomy as a single on/off switch. Users govern agents through guardrails, role tool allowlists, trust levels, blast-radius checks, secret scanning, scoring, telemetry, and repo-visible quality artifacts. This guide explains what each surface does and how operators use it safely.
Guardrails are runtime rules that constrain agent output and repo mutation. They live in the target harness, are attached through the manifest, and can be hard-blocking or advisory. For the full YAML schema, matching behavior, secret-scan details, hook behavior, stale-rule rules, and troubleshooting, open the Guardrails Reference.
| Surface | Where users configure it | Behavior |
|---|---|---|
| Rule files | .harness/guardrails/*.yaml | YAML rules with IDs, messages, severity, scope, patterns, and stale-rule policy. |
| Role attachment | .harness/manifest.yaml | Each role names the guardrail files that apply to its run. |
| Hard guardrails | severity: hard | Block an operation until the violation is repaired or an explicit override path exists. |
| Advisory guardrails | severity: advisory | Inject guidance into role context without blocking a tool call. |
| Built-in policy | MARS tool executor and runtime | Blocks unsafe shell, ticket, file, dependency, validation, deletion, and release operations before mutation. |
Start with narrow, explainable rules. A useful guardrail tells the agent exactly what was blocked and what a safe next action looks like. The Guardrails Reference documents exact field defaults and matching semantics.
roles:
engineer:
guardrails:
- guardrails/safety.yaml
- guardrails/conventions.yaml
rules:
- id: no-hardcoded-secrets
name: No hardcoded secrets
severity: hard
scope: global
pattern: '(?i)(password|secret|api_key|token)'
message: Use environment variables or local secret storage.
rules:
- id: require-tests
name: New code needs tests
severity: advisory
scope: engineer
message: Add or update tests before asking for review.
file_pattern to keep broad regex checks from firing on unrelated files.stale_days values and review stale rules during doctor.Secret scanning is available as an operator command and as an optional git hook. Findings are redacted and should be treated as blockers until the secret is removed and rotated if necessary. The Authentication And Credentials Reference explains where credential values should live.
mars guardrails secret-scan --repo ~/my-project
mars guardrails secret-scan --repo ~/my-project --json
mars guardrails secret-scan --repo ~/my-project --staged
mars guardrails install-hooks --repo ~/my-project
git commit
The managed pre-commit hook runs mars guardrails secret-scan --staged.
MARS keeps agent changes small enough to inspect. Built-in policies classify generated output, dependency churn, ticket lifecycle moves, source writes, validation artifacts, and destructive commands before they can turn into confusing repo state.
Dependency folders, build output, root validation scripts, and dirty generated trees are blocked or routed through explicit cleanup guidance.
Moving the same ticket ID between lifecycle directories is allowed as a bounded deletion exception; unpaired deletions remain blocked.
Audited source roots require valid top-of-file MarsDocSync metadata so code and docs stay connected.
Use external temp outputs such as /tmp/project-validation instead of writing build artifacts into a target checkout.
Trust controls what roles and external clients may do. Manual overrides are allowed, but they require a reason so the audit trail explains why capability changed. Execution profile is an independent outer ceiling: mutation also requires acknowledged host execution, and target trust cannot grant it.
| Level | Meaning | User guidance |
|---|---|---|
observer | Read-only or inspection-oriented access. | Default for external MCP clients and early target evaluation. |
contributor | Can perform governed mutation through allowed tools only inside acknowledged-host execution. | Use for trusted roles or clients doing bounded repo work; trust alone does not grant host authority. |
autonomous | Higher-trust autonomy earned through evidence and policy. | Reserve for roles with proven outcomes and explicit operating rules. |
mars trust --repo ~/my-project
mars trust --repo ~/my-project --db ~/.mars/db/my-project/mars.db
mars trust set engineer ~/my-project contributor \
--reason "Human approved bounded ticket delivery"
The reason is required and should say what evidence or approval justified the change.
Scores turn job outcomes into role health signals. They are not vanity numbers; they help operators understand whether roles are delivering real value, stalling, hitting guardrails, or needing self-improvement work.
| Signal | Examples | User outcome |
|---|---|---|
| Terminal outcomes | Success, partial, failure, timeout, no-op, revert, human follow-up. | Feeds rolling score and trust decisions. |
| Validation evidence | Tests, builds, runtime probes, check results, ticket evidence. | Shows whether work actually shipped behavior. |
| Guardrail outcomes | Policy blocks, secret findings, unsafe shell, dirty workspace. | Identifies safety friction or real unsafe behavior. |
| Factory pace | Turns, tool calls, LLM calls, wall time, limit stops. | Finds roles that are slow, looping, or under-instrumented. |
mars scores --repo ~/my-project
mars scores --repo ~/my-project --db ~/.mars/db/my-project/mars.db
docs/QUALITY_SCORE.md is the repo-visible quality
artifact. It summarizes score evidence, telemetry, ticket state,
dogfood findings, guardrails, check outcomes, no-op signals, human
follow-up, convergence failures, and factory pace while preserving
manual notes.
mars scores export --repo ~/my-project
mars scores export --repo ~/my-project --window-days 30
mars scores export \
--repo ~/my-project \
--create-intervention-debt
Ticket creation is opt-in unless the signal is clearly target-owned.
mars scores export \
--repo ~/my-project \
--db ~/.mars/db/my-project/mars.db
mars checks run --repo ~/my-project --name go-test -- go test ./...
mars scores export --repo ~/my-project --window-days 30
Use this when a test, build, lint, smoke, or release command should count in the quality record.
Telemetry is local-first and off by default. When enabled, MARS can
preview, enqueue, send, collect, and triage sanitized aggregate
reports. Raw target details stay local under the current allowlist;
foundation triage works from repeated minimized patterns. The
configured anonymous mode does not make the network
transport anonymous: the collector and network path can observe
ordinary transport metadata.
| Command | Purpose | Network behavior |
|---|---|---|
mars telemetry status | Shows reporting mode, collector endpoint, DB path, and outbox counts. | No report sent. |
mars telemetry preview | Prints the exact allowlisted aggregate payload for review. | No report sent. |
mars telemetry export --anonymous | Enqueues a sanitized report in the local outbox. | No collector call by itself. |
mars telemetry send | Sends pending reports only when reporting is configured as anonymous. | Calls configured collector. |
mars telemetry collect | Runs a SQLite-backed collector. | Defaults to 127.0.0.1:9092 and rejects every non-loopback or DNS address before opening the collector database. Remote collection is unavailable. |
mars telemetry triage-foundation | Creates MARS source tickets from repeated minimized collector patterns. | Reads collector DB only. |
mars telemetry send requires
telemetry.reporting: anonymous and
telemetry.endpoint. Environment overrides are
MARS_TELEMETRY_REPORTING,
MARS_TELEMETRY_ENDPOINT,
MARS_TELEMETRY_TOKEN, and
MARS_TELEMETRY_INTERVAL.
~/.mars/db/foundation-telemetry/intake.db unless you
pass --db. Use the same explicit path for
mars telemetry collect and
mars telemetry triage-foundation when turning repeated
minimized aggregate patterns into source work.
mars guardrails secret-scan --repo ~/my-project --staged
mars docsync audit --repo ~/my-project
mars scores export --repo ~/my-project
mars scores --repo ~/my-project
mars scores export --repo ~/my-project --window-days 14
mars telemetry preview --repo ~/my-project
mars mcp serve \
--repo ~/my-project \
--trust observer \
--allowlist file_read,file_search,grep,git_status
| Symptom | Likely cause | User action |
|---|---|---|
| A hard guardrail blocks a role. | The attempted operation matched a blocking rule or built-in safety policy. | Read the message, repair the specific issue, or record a deliberate override path if your policy allows it. |
| Secret scan reports a finding. | A staged or repo file looks like a credential. | Remove the value, rotate the secret if it was real, and rerun the scan. |
scores says no scores are recorded. | The selected DB has no scoring evidence yet or the wrong DB was selected. | Use mars start --repo to generate per-repo evidence or pass the expected --db. |
| Quality export says evidence is insufficient. | There are not enough score, trace, ticket, or validation inputs for a claim. | Run real roles, tests, and validation; do not treat sparse data as healthy state. |
| Telemetry send does nothing. | Aggregate telemetry reporting is off or no collector endpoint is configured. | Use mars telemetry status and configure reporting intentionally before sending. |