Case study · Lotus Innovations LLC
Agentic Systems Security Assessment
Subject: our own production AI assistant, a tool-using agent with shell access, device control, and a live credential store.
- Assessment domains applied
- 8Assessment domains applied
- Findings, severity-ranked with evidence
- 11Findings, severity-ranked with evidence
- Closed by re-running the original attack
- 10 / 11Closed by re-running the original attack
- Independent breaks in the exploit chain
- 4Independent breaks in the exploit chain
Why we assessed ourselves first
In 2026, autonomous agents at a frontier AI lab chained ordinary infrastructure weaknesses into a multi-week intrusion that crossed into a second organization entirely. Not one step required novel machine-learning attack theory. Every step was routine application and infrastructure hygiene, with agents supplying the persistence, the concurrency, and the creative recombination.
That incident is why we built a structured assessment methodology for agentic systems. Before offering it to anyone else, we pointed it at ourselves: a production voice and visual assistant we built and run daily, with a tool-using agent that can execute shell commands, control physical devices, and reach a directory of live credentials. We are publishing what it found, including the parts that are unflattering, because a security practice that cannot survive its own methodology is not worth hiring.
What the assessment found
The system was reachable by any device on the local network, and by any website that anyone on that network visited, with no authentication of any kind. Reaching it meant reaching an agent configured to run without permission gates, holding a shell-execution tool. The command filter intended to constrain that shell did not constrain it: commands it flagged as unreviewed still executed, and its approval list could be used to smuggle arbitrary commands past the check entirely.
The practical consequence was a path from an unauthenticated network position to the full contents of a credential store, including keys capable of moving money. A separate path allowed operation of physical door locks.
| Domain | Representative finding |
|---|---|
| Prompt and instruction integrity | Untrusted network input reached the instruction channel with no authentication |
| Tool and action surface | Shell tool ungated; irreversible physical-world action available from a prompt |
| Credential scoping | Entire credential store readable, and reading it was explicitly on the approval list |
| Execution isolation | Service bound to every network interface; unrestricted outbound network access |
| Data governance | An unauthenticated endpoint disclosed the exact filesystem location of every secret |
| Inter-agent channels | Peer client treated as trusted with no authentication |
| AI supply chain | No finding |
| Detection and oversight | Tracing was strong; alerting, rate limiting, and spend caps were absent or bypassable |
The finding that matters most to buyers: no single decision here was reckless. Binding broadly made a peripheral device reachable. Disabling permission prompts made sense for a voice interface, where a prompt is unanswerable. Approving a file-reading command made inspection convenient. Each is defensible in isolation. Composed, they form a remote unauthenticated credential-disclosure chain. Agentic risk is almost never one bad decision; it is the recombination of several reasonable ones by a system that will follow whatever instruction reaches it.
How it was remediated
Ten changes were implemented in dependency order, cheapest and most consequential first. The command filter was rebuilt rather than patched, because the original approach could not be made correct: pattern-matching a shell string is a losing game against an attacker who controls that string. The replacement parses commands into arguments, refuses shell metacharacters outright, and executes without a shell, so command chaining is not filtered but structurally impossible. Interpreters were removed from the approval list entirely, on the grounds that permitting “safe” one-liners while blocking escapes is the same losing game.
Authentication was added to every state-changing route and to both socket endpoints, with browser-origin validation to close the drive-by path. The service was moved to a loopback binding. The credential store, cloud keys, and sensitive project directories were placed behind an explicit deny list. Outbound network access was restricted to known hosts. Secrets were moved out of version-controlled configuration. Spend and rate limits were relocated to the single function every request must pass through.
Verified closure
Every finding was re-tested against the running system. A finding is not closed because a change was made; it is closed because the original attack was re-run and failed.
- Exploit payloads now blocked
- 14 / 14Exploit payloads now blocked
- Legitimate commands still work
- 6 / 6Legitimate commands still work
- Socket authentication tests pass
- 5 / 5Socket authentication tests pass
- Endpoint authentication tests pass
- 8 / 8Endpoint authentication tests pass
Network reachability was confirmed closed by connection attempt, not by reading configuration. Ten of eleven findings are closed; the remaining low-severity item is a data retention policy on an observability tool that is deliberately not running.
What we got wrong, and why we are telling you: the remediation itself introduced two defects, both caught by our own re-test. Removing the shell silently broke a path-expansion behaviour that the shell had been providing. And the new spend and rate limits were first applied at one entry point while leaving another unmetered, the same class of gap as the original finding. Both were fixed and documented. A re-test that finds nothing wrong with its own work is usually a re-test that did not look.
What a client receives
- An action inventory and trust map
- Every tool, function, and integration the agents can invoke, classified by reversibility and blast radius. Most teams cannot produce this from memory, and it stays useful long after the engagement ends.
- A severity-ranked findings report
- Every finding carries the evidence that produced it and a concrete failure scenario in plain language. No finding is written from assumption or from what is typical.
- The exploit-chain narrative
- Individually tolerable weaknesses composed into the realistic end-to-end scenario, written for the person who has to fund the fix.
- A remediation plan sequenced by dependency
- Quick wins separated from structural changes, at code and configuration level.
- Framework coverage mapping
- To the OWASP Top 10 for LLM Applications and the NIST AI Risk Management Framework, for buyers who must demonstrate alignment.
- An optional re-test
- Producing a delta report suitable for a customer, an auditor, or a board.
Why Lotus: most AI security consultants come from security and are learning agentic systems. We came from building agentic systems in production and added the security discipline. We designed tool permissioning, credential scoping, and approval gates for our own delivery pipeline before we assessed anyone’s. That is why our findings arrive with a specific fix rather than a category label: we can read the agent code, not just probe the endpoints.
Scope boundaries
We assess and report; we do not issue certifications or authorizations. Active probing occurs only against non-production environments, only within signed rules of engagement, and only against systems the client owns. Classified environments, controlled unclassified information, network penetration testing, physical security, and social engineering are outside our scope by default.
Book a call
Tell us which system you need assessed. We come back with a fixed scope and a fixed price.