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.

On this page

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.

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.

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.

YsraDocs