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 modern Mac and Windows devices, the camera LED is hardwired to the camera's power circuit. This is not a software feature. It is a physical electrical connection. 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 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.

App Store distribution

Shield is distributed exclusively through the Mac App Store and the Microsoft Store. Both Apple and Microsoft review every app before publishing it, verify the developer's identity, and sign the application binary. This means:

• The app was reviewed for malware and malicious behavior before being published
• The binary is signed and cannot be modified by third parties
• The developer identity (Avalw SRL) is verified
• If a single byte of the app is changed after signing, the operating system will refuse to run it

You can be confident that the app running on your machine is the exact same binary that was reviewed and signed. This is why we recommend downloading Shield only from official stores or from shield.avalw.ai.

How to verify everything yourself

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

• Network activity: Open Activity Monitor (Mac) or Task Manager (Windows). Find Shield and check network usage. It will show zero bytes sent and received.
• Camera access: Check your system privacy settings. Revoke camera access and confirm Shield stops working. Re-grant it when ready.
• Memory usage: Check Shield's memory footprint. It remains stable because frames are processed and discarded, not accumulated.
• Offline test: Disconnect from the internet completely. Shield will continue working with zero degradation, because it never needed a connection.

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