Overview
I was paid to implement security components for an existing AI-assisted CAD-labeling platform used in landscape architecture. I did not build the underlying labeling product. My scope was protecting access to the software and its service-backed functionality, including licensing and key-handling concerns.
I worked through the platform’s original builder. The implementation was AI-assisted. This case study uses a sanitized architectural account rather than publishing client code, credentials, or operational details.
The question
How should a desktop application enforce authorization when the person running it can inspect or modify local files? A local license check is only one part of that problem. The trust boundary also includes the service, update path, session lifecycle, and what happens when the application is offline.
The goal was to make unauthorized use and accidental exposure harder within a defined design. No client-side system should be described as “uncrackable,” and implementation alone does not establish that every attack is prevented.
Design examined and implemented
- Server-backed session opening and continuing authorization checks, rather than treating a local file as the sole authority.
- Signed device challenges and signed responses to give requests and replies verifiable structure.
- Request binding to relevant context, with freshness and replay considerations.
- Session heartbeat and revocation behavior so authorization can change after launch.
- Encrypted handling of protected material and minimized diagnostic exposure.
The important tradeoff: availability
Removing an offline grace path strengthens dependence on current server authorization. It also means a legitimate user may lose access during a service or connectivity problem. Security controls are design choices with operational costs; the appropriate behavior depends on the product’s threat model and availability requirements.
The work therefore belongs as much to systems reasoning as cryptographic implementation. A signature can authenticate a message, but the surrounding application still has to decide what the signed statement authorizes, when it expires, and how failures are handled.
Hardware claims require hardware evidence
The inspected implementation defines a hardware-key interface, but the available provider falls back to software Ed25519 keys. I do not claim verified TPM-backed, non-exportable device identity from that implementation.
This is an important limit because a hardware abstraction, a software fallback, and a tested hardware guarantee are three different things. A security description should identify the actual mechanism, not the strongest mechanism suggested by an interface name.
Testing and retained evidence
Retained historical test reports contain server and desktop checks, negative cases, and regression results. Different snapshots report different scopes: one records 195 server and 404 desktop passes alongside five pre-existing failures; another records 413 passes, eight skips, and nine warnings. These are separate historical receipts, not one combined pass count.
An acceptance-test plan is also present, but a written plan is not an executed test. The review supporting this portfolio did not rerun those suites, and the retained results do not establish current deployment status or comprehensive security certification.
My role and findings
My role was AI-assisted security work on top of an existing product. The meaningful story is identifying authorization and exposure concerns, developing controls around trust boundaries, and checking the consequences of those choices.
Client-specific implementation details remain private. A public discussion should stay at this architectural level unless the client explicitly approves additional disclosure.