What Quasar enforces, and what it only asks

Quasar's rules come in two kinds, and it matters which is which.

Enforced: an agent cannot get past these, whatever it is told.

• It sees only the projects its key's owner can see, and acts with at most that person's rights.

  • A read-only key cannot change anything; the database refuses it.
  • Since 2026.11.1, a key can be limited to some projects and their sub-projects. It then sees nothing else, and none of the organization's settings, people or shared configuration. Setting or changing the limit asks for a fresh second factor.

• Organizations are separated by the database's row-level security.

• The workflow refuses a move its rules do not allow. It can require a plan recorded and checked before work starts, the code having reached a branch as the git host reports it, and a work log.

• Only a person accepts (since 2026.11.1, by default):

  • a document or a release revision is accepted or revoked by a person, never by a key;
  • an agent's working time becomes a work log only when a person confirms it.

  An organization can turn this off, which asks for a fresh second factor.

• Only a project lead can accept a document, accept a release revision or publish a release, and a published release never changes. A Contributor can compose a release, not accept it.

• Sensitive actions need a fresh second factor, which no key can provide. Since 2026.11.1 this includes making somebody a lead: of a project, a division or a team, or by an access grant.

• Every change records the person and the credential that made it, set by Quasar, not declared by the caller.

• The application cannot rewrite its own logs (since 2026.11.1). The database refuses it any update or deletion on the six logs. The two exceptions each go through one database function: erasing a person who was anonymized, and deleting an empty sprint together with its history.

Asked, and recorded: a well-behaved agent does these; Quasar shows when one did not.

• Record the files it really examined in its plan. Quasar checks that the plan was verified and when, but it cannot see the agent's files.
• Move an issue to In progress before starting it, and name the issue in its commit subjects.
• Log time only through work sessions. A Contributor's key can still write a work log directly, with any hours; such a work log is marked as written with a key. So «time logged» is something an agent could fake, and a workflow condition on it proves a log exists, not that it is true.

Not covered today.

• Text inside a project is not checked for instructions aimed at agents: an issue, a comment, a document, a problem report, a CI log. An agent that obeys what it reads acts with its key's full rights. So give agents the narrowest key that does the job: a read-only key for agents that only read, a key limited to the projects they work in, a service account with the minimal role for agents that write.
• The audit trail is not cryptographically sealed. The application cannot change it (above), but whoever administers the database can, and nothing would show it. An item's history is deleted with the item once its trash period ends.
• Antivirus scanning is off until an installation configures it.