What we test.
What we found.
What we changed.
An honest account of how we evaluate Gideon before it touches real work, the safeguards that govern its behavior, and the testing layers that catch what the safeguards miss. This is a living document. It will be updated as our practices evolve.
LIVING DOCUMENT · CURRENT PRODUCT STATESWhat we test.
Every safeguard in Centra is paired with an evaluation that attempts to break it. If a safeguard cannot be tested, it cannot be trusted. These are the areas we evaluate before any change reaches an operator.
Consequential Action Testing
Approval controls let users review requested actions before they proceed. The applicable settings and the action determine when Gideon asks; stronger autonomy settings change that behavior.
Policy Adherence
Gideon operates under user-defined policies: spend limits, allowed tools, approval paths. We test that policies are enforced consistently, that violations generate receipts, and that no policy can be bypassed through conversation or multi-step workarounds.
Absence Detection
Models cannot see what is not there. We test that Centra's absence-detection system correctly identifies missing steps, unverified claims, and incomplete tasks, and surfaces them as actionable items rather than silently moving on.
Receipt Integrity
Every finished run must produce a signed receipt with inputs, outputs, cost, and replay hash. We test that receipts are tamper-evident, that they can be verified without an account, and that the replay hash accurately reconstructs the run.
Memory Boundary Testing
Cortex gives Gideon a timeline and active attention. We test that memory does not leak across users, that sensitive context fades appropriately, and that Gideon cannot be manipulated into retrieving or acting on another user's context.
Multi-Step Attack Resistance
An agent that works over many steps is an agent that can be led somewhere harmful over many steps. We test Gideon against multi-turn manipulation attempts: gradual escalation, context poisoning, and instruction injection through tool outputs.
How we test.
Testing is not a single checkpoint. It is a layered process that starts before a change ships and continues after it is in the hands of operators. Each layer catches what the previous one missed.
Internal Red Teaming
Before a consequential change reaches users, our team attempts to break it. We test approval, policy, evidence, and memory boundaries deliberately and adversarially.
External Review
We work with independent testers to validate our safeguards. External reviewers are given access to Gideon in a controlled environment and asked to find ways past the approval gate, the policy engine, or the receipt system. Their findings feed directly into our next iteration.
Operator Feedback
Every operator in the preview can report issues, unexpected behavior, or near-misses directly through the platform. These reports are treated as safety signals, not support tickets. Patterns across operators inform safeguard improvements.
Continuous Monitoring
Receipts, walk transcripts, and policy violation logs are monitored for anomalies. A spike in approval denials, an unexpected tool call pattern, or a receipt that fails verification is a signal that something needs attention.
What keeps Gideon in bounds.
Safeguards are not features. They are the structural elements that make Gideon safe to hand real work. Each one is designed to be verifiable, enforceable, and impossible to quietly disable.
Approval Gate
Read a requested action, review its scope and decide whether it should proceed. Approval behavior follows your settings and the tools involved.
Policy Engine
Spend limits, allowed tools, approval paths: written in plain language, testable before you ship, and enforced by the console. Every violation writes a receipt of its own.
Walk Inspector
Every run is a traceable sequence of steps: plan, fetch, reason, act, verify. A machine journal that reads like a story and cannot be quietly rewritten.
Signed Receipts
Every finished run ends in a signed receipt. Inputs, outputs, spend, replay hash. Verifiable by anyone, no account required.
Absence Engine
What Gideon did not do is as important as what it did. Missing steps and unverified claims are surfaced as visible items, not hidden behind a confident tone.
Chronos Guardrails
Scheduled tasks and wake-ups inherit the same policies and approval requirements as live runs. Time does not weaken the rules.
An honest account.
Availability does not make safeguards perfect. We separate observed findings, completed fixes, and unfinished qualification, and we do not transfer evidence from one product or environment to another without testing it there.
Early versions of the approval gate could be bypassed when a task was broken into sufficiently small steps that no single step crossed the consequential threshold. The gate now evaluates the cumulative intent of a run, not just the immediate action.
The absence-detection system occasionally flags legitimate omissions as actionable items, for example a deliberately excluded step in a conditional workflow. We are refining the system to distinguish between intentional gaps and accidental ones.
Multi-step instruction injection through tool outputs remains an area of active research. Our current mitigation, sanitizing and labeling tool outputs before they re-enter Gideon's context, reduces the attack surface but does not eliminate it. We are continuing to invest in this area.
This is one half of the picture.
The other half covers our framework for risk assessment, agent governance, security, and the societal commitments we hold ourselves to.