AGR / Labs

Solutions put into practice

Five examples from our internal tools: the problem encountered, the solution chosen and what it produces.

These examples illustrate our work. They are not ready-to-install offers or a guarantee of results in another context.

LAB-01 / Traceability

Tracking technical reviews

The need: As tools change, issues to address can get lost across several documents.
The solution: Bring findings together and track each correction in a registry.
Observable result: A dated report per project and a history of corrections to verify.

View technical details

How it works: A layered audit that can be re-run at will: mapping, threat model, multi-angle collection, then a dated report per project.
Controls and limitations: Findings are reviewed and corrections are accompanied by verification evidence.

LAB-02 / Governance

The need: It becomes difficult to know which automated tasks run and who should respond to a failure.
The solution: Describe each task in a tracked file and keep a log of its executions.
Observable result: Backup, documentation upkeep and briefing tasks brought together in a reviewable record.

View technical details

How it works: Each automation is declared in a versioned file (mission, trigger, instructions), reconciled automatically by the server that runs them.
Controls and limitations: Each task has a defined scope. Changes and executions are recorded.

LAB-03 / Local processing

The need: Some voice notes contain information you want to process on your own workstation.
The solution: Convert speech to text with a recognition engine running locally.
Observable result: Dictated text available for writing, without a remote transcription service.

View technical details

How it works: Speech recognition uses workstation resources, with graphics acceleration when available and a CPU fallback otherwise.
Controls and limitations: Transcription runs locally. Subsequent handling of the text depends on the applications in which it is used.

LAB-04 / Risk control

The need: An automated installation needs to distinguish an expected release from an altered file.
The solution: Check the release’s signature and integrity before installation.
Observable result: A release provenance check built into the update process.

View technical details

How it works: Every published release is cryptographically signed. The workstation verifies integrity and signature before installing, and replaces files atomically.
Controls and limitations: An invalid signature blocks installation. The procedure accounts for interruptions and version checks.

LAB-05 / Controlled actions

The need: An agent connected to email needs explicit limits on its actions.
The solution: Provide specific tools and define access and sending permissions.
Observable result: Messaging and community tasks executed within a defined scope, with reviewable actions.

View technical details

How it works: Every action goes through explicit, named tools, with least privilege on access: the agent can only do what its tools allow.
Controls and limitations: Allowlists govern sending and protections limit destructive actions. External content does not grant authorization.