Framework
Hardening framework for personal AI agents
Your teams will deploy one anyway. Here are the seven points to close first — in the order they close.
Why this framework
Open-source personal AI agents now rank among the most starred projects on GitHub. An employee can install one on their laptop in an evening and wire it into their work inbox — many already have, without anyone deciding to. Up-to-date metrics for these projects are tracked on our Radar.
The tool is not the problem. The problem is that a personal agent plugged into company tools combines three properties that rarely appear together: it reads content written by third parties, it acts on your behalf, and it remembers. Each is manageable; the three together call for a method.
This framework is that method. It doesn't tell you which tool to pick: it tells you what must be closed before you plug anything in, and what we check when we do it for a client.
D1 → D7
The seven control points
Each point presupposes the previous one: you cannot audit the memory of an agent you never learned to log, and you cannot log what you never managed to isolate. The order is our method, not a published standard.
- D1
Access scope
- The risk
- An agent installed with its user's rights inherits everything: the whole mailbox, the shared drive, the internal channels. The first leak isn't an attack — it's a perfectly legitimate read, in the wrong place.
- What we check
- A dedicated service account, rights granted folder by folder and channel by channel, and a written review of what the agent can reach. Never an employee's personal credentials.
- D2
Execution isolation
- The risk
- Running on an employee's laptop or a shared server, the agent becomes a pivot point into the rest of the network — and its secrets sit in the clear next to the machine's own.
- What we check
- A dedicated container, outbound traffic restricted to the domains it needs, secrets injected at runtime and never written into a config file or a conversation history.
- D3
Input attack surface
- The risk
- An agent wired into messaging reads text written by third parties. An instruction hidden in an email, an attachment or a web page becomes a command: that is prompt injection, and it serves exfiltration as readily as action.
- What we check
- A strict separation between system instructions and received content, an allowlist of trusted senders and channels, and mandatory human approval on every outbound action — sending, paying, publishing, deleting.
- D4
Auditable action log
- The risk
- Without a log, an agent's action is indistinguishable from a human one. After an incident, nobody can say what was read, written or sent — nor prove otherwise.
- What we check
- A timestamped log, outside the agent's write scope, recording the action, the data touched and how it was decided (automatic or approved). A defined retention period, and log access separated from agent access.
- D5
Kill switch and taking back control
- The risk
- An agent that loops, picks the wrong recipient or runs on a bad instruction keeps going until someone stops it. "Kill the container" is not a procedure if nobody knows who is allowed to do it at 10pm on a Sunday.
- What we check
- A documented, tested emergency stop, actionable by a named on-call person — and the state of what was done before the stop, readable without restarting the agent.
- D6
Persistent memory and GDPR
- The risk
- Continuous memory is what makes these agents valuable and where their risk concentrates: it accumulates personal data — colleagues, clients, patients — that nobody decided to collect. The right to erasure applies, and a memory you cannot search is a memory you cannot purge.
- What we check
- A written legal basis and retention period, a demonstrated ability to find and then erase one person's data, explicit exclusion of special categories, and the agent entered in the record of processing activities.
- D7
Human control
- The risk
- An agent handed to teams who don't know what it does produces two mirrored failures: blind trust and quiet workarounds. Article 4 of the EU AI Act also requires a sufficient level of AI literacy from the people using it.
- What we check
- A written usage policy — what is allowed, what is not, what requires approval —, traceable user training, and a named contact to escalate abnormal behaviour to.
What this framework does not do
It doesn't rank the tools. These projects change every week; a feature comparison would be stale before it was read. Our watch on them — licence, governance, activity — lives on the Radar, where it updates automatically.
It doesn't replace a data protection impact assessment. An agent touching health data, HR data or minors' data falls under obligations that seven control points do not cover.
It isn't a standard. It is a consultancy framework, published to be reused and argued with. If a point looks misplaced in the order to you, we want to hear the argument.