The security architecture behind Avalw Shield

Most privacy apps ask you to trust them. We built Shield so you do not have to. Zero servers. Zero data retention. Zero network connections. Here is exactly how the architecture works and how you can verify every claim yourself.

The fundamental design principle: zero trust required

When you install a privacy or security application, you are placing an enormous amount of trust in its developers. You are giving an app access to your camera, your screen, and potentially your most sensitive work. Most apps take that trust and route your data through cloud servers for processing.

We took a different approach. We designed Shield so that trust is not required at all. Every architectural decision was made to ensure that even if we wanted to misuse your data, we could not. The system makes it structurally impossible.

The most secure system is not the one with the best encryption. It is the one where sensitive data never exists in a transmittable form in the first place.

Zero server architecture

Avalw Shield has no server. Not a secure server. Not an encrypted server. No server at all.

There is no API endpoint, no cloud backend, no analytics service, no telemetry collection, no update phone-home, no crash reporting server. The application is entirely self-contained on your device.

What this means in practice

• Shield never makes an outgoing network connection. Not on launch, not during use, not on quit.
• There is no account creation, no login, no user ID, no authentication token.
• There is no way for us to push configuration changes to your device.
• If our company disappeared tomorrow, Shield would continue to work exactly as it does today.

Zero data retention

This is the most important architectural decision in Shield and the one that separates it from virtually every other camera-based application.

When Shield captures a frame from your camera, it processes that frame entirely in memory. The frame is analyzed by the on-device machine learning model, which produces exactly one output: an integer representing the number of faces detected, along with basic geometric data about their positions.

That is it. The raw camera frame is immediately discarded from memory. It is never written to disk. It is never saved as a file. It is never cached. It is never transmitted.

The data lifecycle of a single frame

• Capture: A single frame is captured from the camera (not video, a still image every 500ms).
• Process: The on-device ML model analyzes the frame in memory and returns face count + positions.
• Decide: The application logic uses the integer result to determine whether to lock, unlock, or alert.
• Discard: The raw frame buffer is zeroed out and released from memory.

At no point in this process does a recognizable image of your face exist outside of volatile RAM. There is no image file anywhere on your disk. There is no thumbnail. There is no log with timestamps and face data. There is nothing to steal, nothing to subpoena, nothing to leak.

We do not store your face. We do not store an image of your face. We do not store an encoding of your face. We store an integer. That is the entire privacy model.

Memory cleanup after each frame

After each frame is processed, Shield performs explicit memory cleanup. The pixel buffer that held the camera frame is overwritten with zeros before being deallocated. This prevents even theoretical recovery of image data from memory dumps.

This is not standard practice. Most applications simply release memory and let the operating system reclaim it at its leisure, leaving data potentially readable in freed memory pages. Shield actively zeros the data before release, which is the same approach used by cryptographic libraries handling encryption keys.

Hardware camera LED

On every modern Mac, the camera LED is hardwired to the camera's power circuit. This is not a software feature. It is a physical electrical connection on the circuit board. When the camera receives power, the LED turns on. It is impossible to activate the camera without the LED illuminating.

This means you always know when Shield is using the camera. When the green LED is on, Shield is actively processing frames. When you close Shield, the LED turns off immediately. There is no way for Shield or any other application to secretly access the camera.

Screen capture protection

When Shield blurs your screen in response to a Shoulder Guard alert, the blur overlay is rendered using a special window type that is excluded from screen capture APIs. This means that if someone attempts to take a screenshot, use a screen recording tool, or share their screen while Shield is active, the blur overlay will appear in the capture.

This is an important detail. Without this protection, an attacker could theoretically trigger Shoulder Guard and then use a screen recording tool to capture the content behind the blur. Shield prevents this by ensuring the blur is present in all capture methods provided by the operating system.

What we do not do (but others do)

To understand why Shield's architecture matters, it helps to look at what other privacy and security apps commonly do:

Shield does none of these things. Here is a direct comparison:

• Cloud processing: Other apps send frames to servers. Shield processes everything on-device.
• Face embeddings: Other apps store mathematical face representations. Shield stores an integer.
• Analytics: Other apps collect usage data. Shield collects nothing.
• Third-party SDKs: Other apps include tracking libraries. Shield includes zero third-party code.
• Account systems: Other apps require login. Shield has no accounts.
• Network connections: Other apps phone home. Shield has no server to phone.

Code signing and App Store review

Shield is code-signed with an Apple Developer certificate, which provides several guarantees:

• Identity: The code signature verifies that the app was built by Avalw SRL and has not been modified by anyone else.
• Integrity: If a single byte of the application binary is changed after signing, macOS will refuse to launch it.
• Notarization: Apple has scanned the app for known malware and malicious behavior.
• Gatekeeper: macOS verifies the signature and notarization status every time you launch the app.

This means you can be confident that the app running on your machine is the exact same binary that was reviewed and signed. No one has tampered with it in transit.

Integrity hash verification

For users who want the highest level of assurance, you can verify the integrity of the Shield binary by computing its hash and comparing it against the published hash on our website.

We publish SHA-256 hashes for every release. You can compute the hash of your installed binary using Terminal:

shasum -a 256 /Applications/Avalw\ Shield.app/Contents/MacOS/Avalw\ Shield

If the hash matches the one published on our website, you have cryptographic proof that your binary is identical to the one we built and signed. Any modification, no matter how small, would produce a completely different hash.

How to verify everything yourself

We believe that trust should be verified, not assumed. Here is a complete checklist for verifying every privacy claim we make:

• Network activity: Install Little Snitch or Lulu. Monitor Shield for any outgoing connections. You will find none.
• File system activity: Use Activity Monitor or fs_usage to monitor file writes. Shield writes only its preference file. No images, no logs, no databases.
• Camera access: Check System Settings > Privacy & Security > Camera. Revoke access and confirm Shield stops working.
• Memory usage: Open Activity Monitor and check Shield's memory footprint. It remains stable around 50MB because frames are processed and discarded, not accumulated.
• Code signature: Run codesign verification in Terminal to confirm the binary is signed by Avalw SRL.
• Binary hash: Compare the SHA-256 hash of your binary against the published hash on shield.avalw.ai.

Why this matters

Privacy is not a feature you can bolt on after the fact. It is an architectural decision that must be made at the foundation. Once you build a system that sends data to a server, you have created a permanent attack surface. A server can be hacked, subpoenaed, misconfigured, or sold to a new owner with different values.

By building Shield with no server, no data retention, and no network connections, we eliminated these attack surfaces entirely. There is nothing to hack because there is no server. There is nothing to leak because there is no data. There is nothing to subpoena because there is no record.

The strongest privacy guarantee is not a promise. It is an architecture that makes violation impossible.

That is the security architecture behind Avalw Shield. Not a policy. Not a promise. A structural impossibility.

Try Avalw Shield