On-device agent security · FAQ
What security risks do on-device / self-hosted agents face?
Five main classes: an exposed admin panel, skill supply-chain poisoning, prompt injection, the confused-deputy problem (a hijacked agent can’t be told apart from you), and credential blast radius (one box hoards keys to all your accounts). The common thread: the agent can act as you, so one trick becomes real money lost.
How do I check whether my agent is safe?
In three layers. A free surface scan grades the commodity network/auth mistakes A–D on the spot. Our static engine reads the source and flags candidate vulnerable paths. Then a dynamic red-team attacks the running agent to confirm what’s actually exploitable — static ↔ dynamic cross-validation, where the arbiter of truth is whether the exploit worked, not a model vote.
Is there a standard / checklist for on-device agent security?
The TrustShell Open Baseline is an open (CC BY 4.0) checklist of 42 checks across 10 categories — exposure, auth, skill supply chain, permissions, credentials, prompt injection, high-risk actions, audit/forensics, model integrity, updates — with a scoring model (critical checks veto).
What is prompt injection?
Hiding fake instructions in content the AI reads (pages, emails, files); the AI can’t tell “data” from “command” and obeys. For an agent that acts, a successful injection isn’t a wrong answer — it can be a transfer or a data leak. It’s the #1 AI security problem and still unsolved.
What is the confused deputy problem?
A privileged deputy (the agent) is tricked by a third party into doing harm with its legitimate privileges; the system only sees the deputy acting normally and can’t tell who’s behind it. This makes on-device agent incidents un-attributable — the root reason they’re currently uninsurable.
Do cloud-brain agents (like OpenClaw) still need these checks?
Yes. Risk is decided by whether the agent can act for you, not by where the brain runs. OpenClaw-style is agent-local + LLM-cloud: a cloud brain doesn’t reduce local risk — the keys, file-write access, and action execution are all on your machine.
How is this different from an AI code verifier / QC tool?
A verifier reads code and judges whether it looks correct — statically, so it can only guess whether a flaw is real and leans on model voting to suppress false positives. We attack the running agent. A finding is confirmed only when the exploit actually works, and a static false positive dies to a real attack — not a vote. Static tells us where to look; dynamic decides what’s real. That empirical arbiter is something a static verifier structurally can’t give you.
What is TrustShell?
Security for on-device / self-hosted AI agents. We break agents the way attackers will — static reading finds candidate paths, a live red-team proves what’s exploitable (exploit-validated, static + dynamic) — and turn each confirmed break into evidence backed by both the code path and a working exploit: the kind of proof an enterprise review or an insurer can rely on. A free surface scan and an open baseline are the front door; the depth is the product.