Operate
93%
attack success in a 2026 multi-agent computer-use study, up from 73% for a single safety-aligned model.
OS-BLIND, arXiv:2604.105771An agent is a new kind of operator. It needs an identity, not a shared login.
If the agent can read customer data and take action, it is in the same risk class as a person with system access. Treat it that way.
How I see it
AI agent security
Agent security starts with identity and least privilege. The agent should use a service identity, see only the objects it needs, and write only to the fields it is allowed to change.
Then come the agent-specific risks. Prompt injection from documents and emails. Data leaking into prompts and logs. Tool use that was not intended. A user asking the agent to ignore a policy.
The control is not a longer warning in the prompt. It is tool design, allow-lists, output checks, and a refusal path that becomes an exception instead of a clever workaround.
Security review should happen before write-back, not after a pilot has already touched customer records.
Common mistakes
What teams usually get wrong.
Shared human credentials
If the agent logs in as someone, you cannot revoke it cleanly or explain what it did.
Prompt-only security
Instructions are not authorization. Tools and permissions are.
Logging everything forever
Traces can contain customer data. Retention and access are part of the design.
A useful diagnostic
Five questions before you fund the work.
Does the agent have its own identity and permission set?
If it borrows a person’s access, stop and fix that first.Can it only call approved tools with approved arguments?
Open-ended browsing of internal systems is a security product, not a feature.What data is allowed into prompts, traces, and vendor logs?
If nobody can answer, you are not ready for customer or finance data.How do you revoke the agent today?
No kill switch means no production.Have you tested hostile content in documents and email?
That is how injection shows up in real workflows.
Economic model
Access ruleagent identity + least privilege + allow-listed tools + kill switch
If any of these are missing, the agent is not a production operator.
Three credible paths
How far should you go?
Do not force one solution. Choose the path the economics, the risk, and the organization can support.
Read-only with redaction
Let the agent see a limited, cleaned packet.
Security review is still open and the first job is research.
No write-back means limited leverage.
Scoped actions
Allow a short list of writes and external actions under policy checks.
Identity, logging, and a kill switch exist.
Every new tool is a new security review.
Broader operating access
Expand only after incident response, retention, and evaluation are proven.
The agent is already in production on a narrower scope.
Easy to over-grant because it is convenient.
When this is the wrong next step
Do not fund an agent here.
- The company will not give the agent an identity of its own.
- Customer or payment data would enter a tool that has not been reviewed.
- There is no one who can answer a security questionnaire about the system.
A useful next step
Bring one workflow. Get guided into production.
We guide the implementation, go deep on the technical path, and stay hands-on through operations — or tell you when a simpler answer is better.
Discuss an AI opportunity