---
title: Boundaries and safety
sidebar_title: Boundaries & safety
description: The controls built into Ysra today — scope before action, isolated work, credential handling, exact-content approvals, budgets, recovery and audit — and where their limits are.
---

This page describes the controls built into Ysra today. It deliberately
describes *what* each control guarantees rather than how it is implemented.
Compliance certifications are listed only when they are current — not before.

## Scope before action

The repository, knowledge sources, capabilities and permissions for a session
or worker are explicit **before** work starts. Ysra works inside that scope and
nothing wider.

- **Repositories** are reached through an app you install and can revoke. Ysra
  sees only the repositories you grant.
- **Knowledge sources** — Slack, Jira, Gmail — are connected and selected by
  their owner, and each conversation searches only what it was given.
- **Capabilities** such as installing packages, using the network or taking
  destructive actions are allowed, asked about, or denied by your
  [autonomy policy](../workspace/autonomy-policy.md).

## Isolated work

Hosted repository work, and the checks that go with it, run in isolated
environments — never on shared machines, and never on your default branch.
Previews run separately from the workspace doing the coding, so stopping a
preview can't disturb the work.

## Credentials

Credentials are held by the platform and are not given to the model or placed
in the workspace beyond what a specific task needs. Repository delivery,
deployment and third-party actions are separate permissions; being allowed to
edit code does not imply being allowed to publish it.

Every change is scanned for credentials and secrets before it can be delivered.

## External actions need your approval

Where an action reaches outside Ysra — a Slack message, a Jira update, an email —
you see the **exact** content before it runs. Edit it and it waits for approval
again; an approval covers that content and nothing else.

## Budgets and limits

Work is bounded by the budget you set. Ysra stops before the next paid step that
would exceed it, and extending the budget needs your authority. Your account
wallet is a spending limit, not a payment method.

## Checkpoints and recovery

Progress is saved as work happens. An interruption resumes from the last
checkpoint instead of starting over, and you can rewind to an earlier
checkpoint exactly. Rewinding marks the restored version as unverified until it
is checked again.

## Honest failure states

An infrastructure problem is never labelled as a success — or as a defect in
your code. A check that couldn't run is reported as missing, not as passed.
Repeated failures stop the work with an explanation rather than looping.

## Auditability

Sessions record their events, tool activity, usage, artifacts and delivery so
you can see what happened and what it cost. Reasoning is summarised as the
actions and observations that drove the work; internal model reasoning is not
exposed.

## Where the limits are

- The security scan is a **baseline**, not a penetration test or a substitute
  for your own review.
- Browser proof covers the behaviour that was exercised, not every path through
  the application.
- Ysra does not mirror every permission in your organisation; it searches the
  sources you select for it.

!!! info "For security reviews"
    Bring your questionnaire. We'll walk your team through data flows,
    isolation, credential handling and the audit trail for the workflows you
    plan to use — and say plainly where the boundaries are today.