Thraksha Guardian
Security should not only detect. It should understand, explain and help you respond.
An Android proof of concept exploring how device security, evidence, local AI and safe automation can operate as one system.
- Frozen proof of concept
- Android
- Local-first AI
Last verified
Empty on purpose. A mockup or a generated screen would be a picture of something that was never on the device, on a page whose whole argument is that it does not overstate.
The idea, in plain terms
No security knowledge needed for this part.
A scanner can find things.
It looks at what is installed and what it is allowed to do.
An assistant can understand you.
You say something in ordinary words and it works out what you meant.
An automation system can change things.
It adjusts settings on the device for you.
Those three usually live in separate apps that know nothing about each other. Thraksha asks what happens when they work from the same understanding of your phone — while still keeping them from becoming the same authority.
The loop
- See
- Understand
- Explain
- Confirm
- Act
- Verify
- Restore
Why build it this way
Most of us can press Allow. Far fewer of us could say what we just allowed.
A phone asks for a permission and you decide in about a second. Afterwards, most people could not say what that permission actually enables, whether it is still granted, why the app wanted it, or whether anything was ever actually done with it.
None of that is a failure of attention. The information is genuinely technical, it is spread across several screens, and the interesting part — whether several individually reasonable signals add up to something worth looking at — is not shown anywhere at all.
From
“Here are your permissions.”
Toward
“Here is what we observed, here is why it matters, here is what we do not know, and here are your options.”
What if your security system and your automation assistant understood the same device?
This is the part the prototype exists to demonstrate.
You say: “I have a meeting for 45 minutes.”
The model interprets that on the device and builds a plan. The plan is shown to you before anything happens. Nothing runs until you press start.
Supported settings are then changed, and the device state that actually resulted is checked — not assumed. When the 45 minutes are up, the previous state is put back.
The step usually missing is the second to last one: asking afterwards whether the change did what it said it would.
- Understand
- Preview
- You approve
- Act
- Verify
- Restore
AI understands. Security verifies. You decide.
The language model runs on the device and can interpret an ordinary spoken request, but it is kept separate from the part of the system that holds security truth. It explains and interprets; it does not decide, and it is not the record. A model that both describes your device's security and is trusted as the account of it can be wrong twice and sound right both times.
How the security side works
The short version first. Open a panel only if you want the detail.
Thraksha looks at what is installed, what those applications are able to do, and what connections the device is making. It records what it observed and where each observation came from, rather than turning everything immediately into a single number.
That record is the point. A score cannot be argued with; a list of observations can be read, questioned and — if it is wrong — corrected.
What it looks at on the deviceDetail
Installed applications and what they are able to do, gathered from the device itself rather than from a declared list. Getting a complete inventory turned out to be one of the harder problems in the project, and it is described in the engineering section below.
How network activity is observedDetail
Network Guard uses Android’s own VPN capability, locally on the device, to observe supported connection metadata. It does not route your traffic anywhere, it does not decrypt encrypted content, and it does not see every packet. Encrypted traffic stays encrypted — that is a property of the traffic, not a limitation better engineering would remove.
How findings are recordedDetail
Actions and findings are kept as an encrypted audit record on the device, so the system can be questioned after the fact rather than only trusted in the moment.
What makes the approach interesting
These are architectural choices, not claims that other software cannot do the individual pieces.
Security and automation share one picture of the device
The part that scans and the part that changes settings read the same evidence rather than each keeping a private idea of what the device looks like. That shared context is the actual experiment.
The AI interprets; it never becomes the authority
The model turns a sentence into a proposed plan. Whether that plan is permitted, and whether it worked, are decided elsewhere by code that does not consult the model.
Evidence instead of a risk score
A single number is easy to display and impossible to check. Thraksha shows what was observed and where it came from, so a reader can disagree with the conclusion.
Changes are designed to be undone
Anything the system alters is captured first and restored afterwards. Reversibility is a property of the architecture, not a feature bolted to the end of it.
The model runs locally
Interpretation happens on the device. Nothing about the device's security posture has to leave it in order to be explained, which is the reason the project exists.
Unknown stays unknown
Where the platform will not say, the answer is “not observable”. It is never rounded up to “safe”, because the difference between those two is the whole value of the report.
Actions are bounded by policy
What may be changed at all is constrained by a policy layer that sits outside both the model and the automation, so the boundary is not something a prompt can talk its way past.
To be explicit, because the above would be easy to read as a swipe at something: conventional security products are not wrong, and many of them will outperform this prototype in particular areas. Thraksha was exploring a different question, not competing on the same one.
What Android will not let it do
Not a caveat at the bottom of the page. It is the thing that shaped the design.
Android isolates applications from each other deliberately, and that isolation is a feature — it is a large part of why a modern phone is a harder target than a desktop computer used to be. It also means an ordinary application cannot see everything happening on the device it is running on.
Some Wi-Fi, radio, Bluetooth, kernel and system information is simply not available to an app. Encrypted content stays encrypted. Some actions need privileges a consumer install has no business holding.
So the design has a rule for what to do at each boundary, rather than an excuse for crossing it.
- Observable
- Analyse it.
- Verifiable
- Verify it.
- Unobservable
- Say so, plainly.
- Actionable
- Require the appropriate authority.
- Uncertain
- Never silently call it safe.
Designing within Android's boundaries
Not working around the platform's protections — working inside them, and saying so when they stop you.
When Android will not expose it, report it as not observable
The absence of evidence is written down as an absence rather than left as a gap the reader fills in optimistically.
Read the network metadata Android does expose
Network Guard uses Android's own VPN capability to observe supported connection metadata on the device. It does not decrypt encrypted content and does not see every packet.
Use Android's supported special-access paths for automation
Settings that require elevated access are reached through the routes Android publishes for them, with the user granting access through the system's own screens.
Keep privileged verification in a controlled environment
Device Owner grants management authority that is inappropriate for an ordinary consumer install, so privileged paths were verified on a dedicated emulator rather than shipped to a personal device.
Advise rather than act on ordinary personal devices
On a normal personal phone the system runs in an advice mode: it explains what it would do and what the user can do, without holding privileges it should not have.
Ask the person when Android requires a person
Where the platform demands explicit human interaction, that interaction is part of the flow rather than something the design tries to route around.
What building it taught us
Every one of these was a real problem on a real device. None of them is embarrassing; they are the reason the thing works.
01
The release build could see fewer installed packages than the debug build.
- Investigation
- The gap was traced to package visibility configuration, which Android applies differently once an application is built for release.
- Resolution
- The visibility configuration was corrected for the release build.
- Verification
- Counted against the device's own ground truth: 441 of 441 packages visible, including all 23 owner-installed applications.
02
The local model held on to several gigabytes of memory.
- Investigation
- Traced to how the model's lifecycle and the system's memory-pressure signals were being handled.
- Resolution
- Lifecycle and memory-pressure handling were rewritten.
- Verification
- Re-measured on the device after the change.
03
Automation had to put the device back exactly as it found it, not approximately.
- Investigation
- Restoring from assumptions about the previous state was unreliable, because the assumption and the device could disagree.
- Resolution
- A snapshot, execute, verify and restore sequence was built, so the previous state is captured as fact before anything changes.
- Verification
- Exercised end to end on the device, including after a reboot.
04
The very first AI request hit a runtime state-transition fault.
- Investigation
- Reproduced and diagnosed from real-device behaviour rather than from the emulator alone.
- Resolution
- The state transition was corrected.
- Verification
- Re-run on the device.
05
Pressing the system Back button on the plan preview exited instead of cancelling the plan.
- Investigation
- Found in device testing, not in unit tests — it was a question of what the gesture meant, not whether the code ran.
- Resolution
- Back now cancels the pending plan, which is what a person expects.
- Verification
- Confirmed by repeating the gesture on the device.
06
Device Owner behaviour could not be validated on the ordinary test phone.
- Investigation
- Provisioning Device Owner on a normal personal device is not an appropriate thing to do, and not a state to leave a phone in.
- Resolution
- A dedicated Device Owner emulator image was set up for the privileged paths.
- Verification
- Privileged behaviour verified there; the physical device kept to the unprivileged path.
What was actually verified
Each result carries the weight it can bear and no more. These are the project's own measurements of itself — nobody else has reproduced them.
Full package visibility on the verified device
441 of 441 packages visible in the release build, checked against the device's own list.
All owner-installed applications visible
23 of 23 real owner-installed applications enumerated and scanned.
Scanning does not modify the device
The scan path reads; it does not write, remove or alter what it finds.
The AI works with no network at all
Interpretation ran with the device in airplane mode.
Automation runs, verifies and restores
A timed routine changed supported settings, confirmed the resulting state and returned the device to its previous one.
State survives a reboot
Reboot and upgrade persistence were explicitly exercised.
Regression coverage
Unit tests and repeated on-device regression runs across the build.
Privileged Device Owner paths
Verified on a dedicated emulator image only. Not exercised on the physical test device, deliberately.
Contents of encrypted network traffic
Encrypted traffic stays encrypted. Only supported metadata is observed.
Detection of any and all attacks
No claim is made that every compromise is observable to an application on an ordinary phone.
Independent security audit
Nobody outside the project has reviewed or audited this work.
Technical detail
For developers and security engineers. Nothing here is needed to understand the rest of the page.
Architecture and separation of authority
Three concerns are kept apart on purpose: an evidence and security layer that records what was observed, a model runtime that interprets language, and an automation layer that changes state. The model can propose; only the security and policy layers permit, and only the automation layer acts. The separation is structural rather than a convention, so a mistake in one does not become authority in another.
Security and evidence pipeline
Observations are collected, attributed to where they came from, and kept as evidence rather than being collapsed immediately into a verdict. A finding can therefore be re-read later and disagreed with, and the audit record shows what the system actually saw at the time.
Threat rules
Rules are packaged and applied to collected evidence rather than being scattered through the scanning code, so what counts as notable is inspectable in one place instead of inferred from behaviour.
Package visibility
Android restricts which other applications an app may enumerate, and applies those restrictions differently between debug and release builds. Getting a complete and honest inventory required configuring visibility deliberately and then checking the result against the device's own package list rather than assuming it.
Network Guard and the local VPN
Android exposes a VPN capability that an application may use locally. Thraksha uses it to observe supported connection metadata on the device itself. It is not a proxy service, it does not send traffic anywhere, and it does not decrypt content — encrypted traffic remains encrypted.
On-device model runtime
The language model is loaded and run on the phone. That constrains what size of model is usable and makes lifecycle and memory pressure a first-order design problem rather than an afterthought — which is exactly where one of the harder bugs in the project turned up.
Model integrity
The model artefact is checked before it is trusted, so the runtime is not loading whatever happens to be present under the expected name.
Safety policy
A policy layer defines what may be changed at all. It sits outside both the model and the automation, so the set of permissible actions is not something a cleverly worded request can extend.
Automation state machine, snapshot and restore
Automation is a state machine rather than a script: capture the current state, present a plan, wait for explicit approval, execute, verify the state that actually resulted, and restore afterwards. Verification after the fact is the step usually missing — asking whether the change did what it said it would.
Encrypted audit trail
Actions and findings are persisted as an encrypted record on the device, so the system can be questioned afterwards rather than only trusted in the moment.
Advice Mode and Device Owner
Two postures. On an ordinary personal device the system advises: it explains what it would do without holding privileges inappropriate for a consumer install. Device Owner grants real management authority and was used only in a controlled emulator environment to verify the privileged paths.
Testing strategy
Unit tests for logic, and repeated regression runs on real hardware for everything that only misbehaves on a real phone — memory pressure, first-run state transitions, reboot persistence and what a gesture means. Several of the bugs worth fixing were only visible on the device.
Release build and offline verification
The release build is signed, and the behaviours that matter were re-checked in that build rather than only in debug — the package visibility problem existed only in release, which is the argument for verifying the artefact you would actually ship.
What Thraksha is not
Stated directly, so none of it has to be inferred from silence.
- Not a replacement for antivirus or any established security product.
- No claim that a device running it cannot be compromised.
- Not proof that every attack can be detected.
- Not full inspection of encrypted network traffic.
- Not unrestricted AI control over the device.
- Not a consumer product, and not on a path to becoming one at any stated date.
- Not independently security audited.
And the limits, in full
- It is a prototype and it is frozen. There is no release, no download and no install route, and this page is not an announcement that one is coming.
- Android only. Nothing was built for any other platform.
- It can only observe what Android permits an application to observe. Android isolates applications on purpose, and some Wi-Fi, radio, Bluetooth, kernel and system information is simply unavailable to an ordinary app.
- Encrypted network content stays encrypted. Only supported metadata is visible.
- Some actions require privileges an ordinary consumer install should not hold, so on a personal device the system advises rather than acts.
- It does not claim to detect attacks, prevent compromise, or tell you that a device is safe. It reports what it can see and explains why that might matter — a much narrower claim, and the only honest one.
- Nothing here has been independently audited, reviewed or tested by anyone other than its author.
- None of it is publicly verifiable today. The repository is private, no build is distributed, and every figure on this page is the project's own recorded result rather than one anyone else has reproduced.
Where the idea could go
A direction, not a roadmap. No dates, and nothing to sign up to.
Thraksha Guardian is frozen. What the experiment suggests is a larger idea: a personal security layer that belongs to one person and their devices, keeping its understanding local wherever the platform allows it.
Android was the first environment explored because it exposes enough to make the question answerable. Other platforms would each permit a different amount, and an honest version of this would use only what each one genuinely allows rather than promising the same thing everywhere.
Further research could look at deeper personalisation, changing threat intelligence, stronger local reasoning, and a personal security history that stays on the device.
A separate concept called Thraksha Personal is being explored along those lines. It is a research direction and not an announced product: there is no code behind it, no date, and nothing to join.
Thraksha is not an attempt to replace every security product. It is an exploration of another way security can work: observe what can be observed, understand what it means, explain it to the person, act only with authority, verify what happened, and never pretend to know what cannot be known.
Security should not become less rigorous when intelligence is added to it.
What this is based on
Sources for this page
- Thraksha Guardian — private prototype repositoryprivate source — described, not linked
A private repository holding the completed Android proof of concept: device and application scanning, network monitoring, on-device model interpretation, previewed and reversible automation, encrypted audit persistence, and its automated test suite. It is not published, no build is distributed from it, and it is named nowhere on this site.
Checked 26 August 2026
- Thraksha Guardian — verification results recorded on the test deviceprivate source — described, not linked
The project's own recorded results from its Android test device: 441 of 441 packages visible in the signed release build, all 23 owner-installed applications enumerated, scanning confirmed non-destructive, model interpretation run with the device in airplane mode, a timed automation routine executed and the previous state restored, and reboot and upgrade persistence exercised. Privileged Device Owner paths were verified on a separate emulator image rather than on the physical device. These are the project's measurements of itself; no third party has reproduced them.
Checked 26 August 2026
- Founder account — what the Thraksha prototype does and what state it is inprivate source — described, not linked
Supplied by the founder on 2026-08-26: the design intent, the engineering problems encountered and resolved during the build, the boundaries the design works within, and the state the project was frozen in. The prototype was built and tested on real Android hardware and no release is planned or announced. Everything described on this site comes from this account, the recorded device results and the private repository. No screenshot, recording or test report has been published, so none of it is independently verifiable today.
Checked 26 August 2026
This is the least externally verifiable page on this site, and that is worth saying plainly. Everything above rests on a private repository and the project’s own record of its own results. If that matters to you — and for a security project it reasonably might — treat it as a description of work rather than as a claim you can check. The corrections page explains how anything here gets fixed if it turns out to be wrong.