An agent completed its first support task correctly, then revealed the real security problem. The same credential that let it read an order could refund it, edit the customer and delete the record. The prompt said not to. The system had no reason to trust that sentence as a security boundary.
An agent with a broad API key is not an assistant with good judgement. It is an integration with excessive authority and a probabilistic controller.
Start from capabilities, not accounts
Do not ask which employee account the agent should use. List the exact operations the workflow requires. Reading order status, adding an internal note and proposing a reply are separate capabilities. So are sending the reply, issuing a refund and changing an address.
Expose these as narrow tools with typed inputs and explicit outputs. A tool named manage_order hides too much. Tools such as get_order_status, draft_support_note and request_refund_approval make authority visible in code and logs. Validate identifiers, allowed states and amounts outside the model. The agent may choose a tool, but it should not define what that tool is allowed to do.
Scope the credential behind the tool
The model should never receive a reusable secret in its context. Credentials live in the server-side tool layer and are selected for the operation. Use separate service identities for separate workflows, with short-lived tokens where the provider supports them. Restrict audience, resources and actions.
This is ordinary least privilege, not an AI-specific invention. The OAuth security best current practice recommends limiting access-token privileges to the minimum required and restricting tokens to intended resources and actions. The important part is enforcement by the resource server, not a promise in the system prompt.
Avoid sharing one integration key across development, testing and production. Rotation should be possible without editing prompts or redeploying unrelated agents.
Read-only is the useful default
Begin with retrieval. Let the agent assemble context, classify work and propose an action while a person or deterministic service performs the write. This is not because every write is dangerous. It is because read paths reveal missing data, ambiguous identifiers and unexpected edge cases before those weaknesses can change business state.
Add write access operation by operation. Idempotent writes with narrow consequences can be automated earlier. Irreversible actions, money movement, external communication and permission changes need stronger gates. Approval must bind to the exact proposed payload. A generic approve button followed by a regenerated action is not approval of that action.
Keep an audit trail that can answer why
For every tool call, record the agent run, authenticated principal, tool name, validated arguments, policy decision, result reference and time. Do not put raw secrets or unnecessary personal data in the log. Keep enough information to reconstruct what changed and which evidence the agent used.
Logs should distinguish a model proposal, a policy rejection, a human approval and a completed side effect. That separation matters during an incident. It also makes evaluation possible: the team can see whether failures came from retrieval, reasoning, policy or the downstream system.
Tighten one workflow this week
Choose the agent with the broadest credential. Inventory every permission it currently has and every tool it actually used in recent successful runs. Create a new service identity containing only the intersection. Put destructive or externally visible operations behind explicit approval and make retrieval the fallback when policy is uncertain.
Then test denied paths deliberately: another tenant's record, an excessive amount, a repeated request, an expired token and a tool call with an unknown field. A secure agent is not one that never asks for the wrong action. It is one whose surrounding system can refuse that action cleanly, record the refusal and continue safely.