Keep related signals together
Different authentication warnings were tracked together within that context, so subsequent actions could face stronger checks.
April 12, 2026 · Controlled service and route tests
Ardamire Defense Layer
Controls that act
Records you can inspect
Ardamire is Auxtho's internal defense layer for AI-assisted document workflows and their backend. It grew out of our work on controlled execution and retries.
Our recorded April implementation connected related anomaly signals, targeted holds, replay-evidence checks and separately reviewed defensive changes.
Recorded April 2026 work · Auxtho-owned test environments · Prepared October 3, 2026
Implemented controls / recorded April tests
The next action faced stronger controls
Within the tested operator and workflow context, related anomaly signals accumulated. Additional verification or a hold governed what could happen next.
Contain the affected object
Artifact and export mismatches led to targeted holds. The tests distinguished the affected object from unrelated work.
April 12, 2026 · Controlled service and route tests
Keep the investigation readable
Invalid replay results were excluded from accepted replay evidence. Their results and reasons remained available for investigation.
April 13, 2026 · Controlled local workflow
What the controlled tests checked
- Related signals changed the next action. Different authentication anomaly signals accumulated within a bounded context. A challenged operator could still read the permitted authentication state, but a state-changing request required additional verification.
- A weak signal did not immediately stop the workflow. A single weak missing-export signal did not trigger quarantine. Repeated signals for the same object led to an artifact/export hold, rather than a whole-run hold.
Selected assertions from preserved implementation tests, corroborated by recorded April 12 service/route test runs. These describe tested behavior, not newly captured production traffic or a measured attack-learning rate.
The system
Recorded signals, strengthened checks, enforced holds and prepared investigation evidence.
The person
Reviewed exceptions and authorized consequential defensive changes.
Actual screen excerpts / April 13, 2026
Keep the state Keep the reason
These are cropped original screen records from controlled local tests with seeded test data, not reconstructed UI or footage of a new attack.
The object remained contained
The screen retains the containment state. A hold did not itself resolve or close the incident.
Keep the valid record Exclude the invalid result
One verified baseline replay remained in accepted evidence. Eight invalid results were excluded, including seven marked high risk. The excluded results and their reasons stayed available for investigation.
- Verified baseline retained
- 1
- Invalid results excluded
- 8
- High risk, within the eight
- 7
Here, “verified replay” means that the result passed integrity and recorded request/execution-binding checks. It does not establish the truth of every AI-generated document or finding.
A separate review for a defensive change
The requester could not approve their own reactivation
In the recorded local workflow, a disabled defense-rule proposal could return to shadow evaluation only after a request and review by a different authorized person. The requester could neither review nor apply that reactivation; applying it required the approved reviewer. Shadow evaluation assessed the proposal without changing production rules.
Original pixels retained; surrounding internal identifiers removed by cropping. Replay-result counts are not attack counts.
Auxtho-owned live backend / April 15, 2026
The action stopped
The record stayed readable
An unknown operator or wrong token issuer was rejected. Replay attempts without a required prior step, or after a recorded failure, were rejected. Incident detail stayed available.
Identity / state checks
Identity, state transitions and permitted requests.
0 expectation failuresMethod / schema checks
Request methods, body validation and a permitted request.
0 expectation failuresRequests in extended soak
Normal reads and invalid requests under sustained pressure.
0 expectation failuresThree separate recorded suites on Auxtho's own then-live backend. Counts include normal requests; they are not counts of attacks prevented.
Allowed work mattered too
The identity/state suite recorded five expected successful requests alongside its rejection checks. After a failure was recorded, another replay was blocked, but the permitted incident-detail read still succeeded.
One incident One bounded request A readable result
These steps came from the same recorded incident and request in the identity/state suite—not separate cases assembled into a success story.
- C01 · 200Create the test incident
Incident intake succeeded.
- C02 · 200Create the bounded request
The sandbox request was recorded.
- C03 · 409Reject premature replay
The required prior step had not occurred.
- C04 · 200Accept the required step
The request was claimed for execution.
- C05 · 200Record the failure
The test's failed execution was recorded successfully—not treated as a successful execution.
- C06 · 409Reject replay after failure
The recorded state prevented another replay.
- C07 · 200Keep the incident readable
The permitted detail read still succeeded.
All seven expected and recorded status codes matched. These are seven of the existing ten checks, not an additional suite. The identity rejection checks below were separate probes.
| Tested case | Expected | Recorded |
|---|---|---|
| B01 · Identity / stateUnknown operator | Rejected401 | Rejected401 |
| B02 · Identity / stateWrong token issuer | Rejected401 | Rejected401 |
| B03 · Identity / stateReplay before a required prior step | Blocked409 | Blocked409 |
| B04 · Identity / stateReplay after a recorded failure | Blocked409 | Blocked409 |
| B05 · Identity / statePermitted incident-detail read after failure | Succeeded200 | Succeeded200 |
| B06 · Method / schemaDisallowed replay request method | Rejected405 | Rejected405 |
| B07 · Method / schemaReplay request missing required body fields | Rejected422 | Rejected422 |
Tested by Auxtho on its own then-live backend. These seven rows are selected excerpts from two preserved result files; all seven recorded status codes matched their expectations. Case labels are simplified, and internal identities, endpoints and request details are omitted. The downloadable record identifies each selected row. These checks do not measure an overall false-positive rate.
Earlier pressure test: two client timeouts, then a separate rerun
An earlier April 15 mini-soak issued 648 requests and recorded two client read timeouts. After the test client's timeout budget was adjusted, a separate 648-request rerun recorded no expectation failures. That is a changed test condition, not proof that a backend defect was fixed.
The later extended soak shown above comprised 1,296 pressure requests and 124 follow-up requests: 1,420 in total. These distinct runs are not combined into an attack count or learning score.
Connected execution foundations / April 11–12, 2026 KST
Find the failure
Fix the path Run it again
EP19 blocker records informed Ardamire's incident and signal-history work while Ardamire development also proceeded in parallel. The related EP19 operator-runtime program tested execution and retry behavior. The original run shown here completed 80 cycles and recorded six scenario failures. After retry handling and test isolation were corrected, the rerun completed 80 cycles with none; scenario allocations changed between runs, so this was not a matched attack-learning comparison.
- 01 / Find
Six failures stayed on the record
Failures concentrated in retry creation, acknowledgment-to-retry timing and timeout progression.
- 02 / Correct
Correct the path and the test setup
Retry creation gained duplicate-request handling; the runtime supervisor was reset between test cycles.
- 03 / Verify
Complete another 80-cycle program
The rerun recorded no scenario failures. Its changed scenario allocations do not establish an attack-learning improvement.
| Phase / test mix | Cycles per run | Original failures | Rerun failures |
|---|---|---|---|
| 0 · Baseline stabilization | 4 | 0 | 0 |
| 1 · Normal / duplicate-heavy | 16 | 0 | 0 |
| 2 · Alert-heavy | 16 | 5 | 0 |
| 3 · Failure / chaos | 20 | 1 | 0 |
| 4 · Mixed soak | 24 | 0 | 0 |
| Total / each run | 80 | 6 | 0 |
Local isolated validation stack. The rerun's observed span was about 19 hours 53 minutes against a configured 20-hour program. Phase mixes differed; scenario allocations changed between runs. This is runtime validation connected to Ardamire's development, not a sequence of Ardamire breaches or a measured attack-learning rate.
Where these records connect to Ardamire
EP19 blocker records became inputs to Ardamire's incident, profiling and signal-history work. Ardamire implementation also proceeded in a parallel development session; the EP19 closure was not the start date of all Ardamire work.
The recorded runtime corrections, Ardamire controlled local workflows and own-backend suites are separate evidence sets. Their counts are not combined into one security score.
Read the evidence
Built Tested Recorded
The four-page record covers Ardamire's April implementation and tests. The separate web record adds the execution-foundation history shown above.
Ardamire implementation & tests4-page PDF · Original published version · 58 KB↗
Selected recorded test outcomesPublic JSON · Expected / recorded results, dates and phase history↗
These are dated implementation and test records, not an independent security certification or evidence of customer-wide protection. They do not establish the readiness of today's hosted restoration.
Model explanation / separate from test evidence
See the modeled path from detection to verification before rollout
This illustrative sequence explains the control structure. It is not a live incident stream or a replay of the recorded tests above.
Ardamire / six-stage control sequence
Interactive control sequence / modeled signal scenario
Current modeled stageReady to play sequence
- 01Detect
A security signal enters the defensive control path.
- 02Quarantine
The affected path enters a hold state while the signal is investigated.
- 03Analyze + Profile
Signal, artifact, and policy context are assembled for review.
- 04Harden proposal
A defensive change is prepared as a proposal, not executed.
- 05Human review
An accountable person decides whether the proposal advances.
- 06Verify before rollout
The approved proposal enters a separate verification stage before rollout.
One controlled workflow
Keep the signal, decision and result connected
Start with one Auxtho-managed workflow. Identify the affected work, the supporting evidence, the responsible reviewer and the verification required before a defensive change advances.
Discuss a workflow
Ardamire's scope is Auxtho's workflow and backend, not the customer's entire security environment.