Can AI agents be secured with software alone?

In detail

Guillemet’s case for protecting valuable signing keys

Charles Guillemet, CTO of Ledger, puts it plainly: “Securing an agent is not something possible.” His concern is agents entrusted with valuable assets and credentials. The first problem is alignment. Human language is ambiguous, and agents are non-deterministic, so translating what you asked into a deterministic action is hard, and sometimes the agent does something slightly different from what you meant. The second is secrecy. To act on your data or your money, an agent needs credentials: API keys, or the 24 words behind a crypto wallet. If credentials enter model-visible context, prompt injection creates an exfiltration risk. Guillemet points to a recent case where an account on X was prompt-injected just by tweeting at it, and lost money.

Delegate rights, don’t hand over keys

Guillemet proposes delegating rights rather than handing the model credentials. You define policies, and a policy engine checks proposed actions against them. The hard part is formalization: making sure an intent maps to a specific action. He suggests hardware-backed policy signatures to establish who approved the policy. A signature authenticates an approval; it does not establish that the policy captures every part of the user’s intent.

Prove the engine ran as written

Guillemet separates correct policy execution from key protection. He discusses running an engine in a trusted execution environment, or proving its computation with a zero-knowledge proof. He qualifies the enclave approach as “not that secure, but it’s better than full software.” In his proposed flow, a policy check precedes the protected signing operation. These mechanisms protect specific parts of the execution path; they do not prove the policy is sensible or the model’s recommendation is correct.

Match the tier to the threat model

Guillemet describes increasing friction as asset value and attack incentives rise: software access controls, protected automatic signing, a hardware device where a person inspects the operation, and a quorum of hardware-backed approvals. He cites Ledger’s firmware signing as a quorum example. These are his threat-model tiers, not a claim that any named secrets-management product necessarily uses hardware. Choose the controls for the assets and failure modes you actually need to protect.

In Guillemet’s proposed signing design, hardware protects the keys. That does not replace the permission model. See agent identity and permissions for how governed data access, task-scoped identity, and action control determine what reaches that layer.

Put enforcement outside the model

OWASP’s excessive-agency guidance calls for downstream authorization. A model’s instruction to stay within scope is not the component that should enforce that scope. Narrow the available operations, give tools only the necessary permissions, and check authorization on each request. OWASP’s prompt-injection guidance also recommends approval for high-risk actions and keeping credentials out of model-visible context.

Illustrative test: an invoice contains an instruction to export customer records. The invoice is data, not authority. A read-only invoice assistant should have no export or payment operation. A payment assistant needs a separate policy check for the exact recipient, amount and approved action before any signature is issued.

Keep both sides of each test. A system that refuses everything can look safe while failing its purpose. Inspect tool and downstream logs: a reassuring refusal message does not prove the prohibited call was blocked.

Check yourself

If a key is protected by hardware, is every signed request legitimate? No. Key isolation and action authorization solve different problems. Guillemet’s hardware proposal strengthens the signing boundary; the policy still has to express the user’s intent correctly. Read agent identity and permissions alongside context poisoning before expanding access.