The risky part of an agent is not that it can talk.
The risky part is that it can act.
Once an agent can read files, call tools, edit code, send messages, create tickets, change records, trigger workflows, spend money, or deploy software, security is no longer only about model behavior. It is also an access-control problem.
That does not make model safety irrelevant. It means model safety is not enough.
The first security question should be concrete: what can the agent read, write, execute, send, spend, deploy, or delete, and whose authority is it using when it does those things?
Tool access changes the threat model
A chatbot with no tools can still create risk through bad advice, data leakage, or misleading content. A tool-using agent adds system risk.
Imagine a code agent that can open a pull request, modify a deployment file, and notify a channel. Each action has a different blast radius.
The agent may not deploy directly, but it can edit a deployment file, open a pull request, tag an approver, and set a production path in motion. The action chain matters as much as the tool name.
Reading a repository is not the same as writing to it. Opening a pull request is not the same as merging it. Updating a deployment file is not the same as deploying to production. Sending a Slack message is not the same as changing a customer record.
If one broad permission covers all of those actions, the architecture is doing too little work.
The agent needs scopes. The workflow needs approvals. The trace needs to show what happened. The team needs a rollback path for reversible actions and stronger controls for the actions it cannot undo.
Read. Write. Execute. Send. Spend. Deploy. Delete.
Each verb deserves its own boundary.
The controls that matter early
I would start with identity.
Is the agent acting as the user, as a service account, or as a delegated workflow identity? That choice changes audit, ownership, and permission design. If an agent takes an action, the organization needs to know whose authority was used and why.
Then least privilege. The agent should get the minimum access needed for the task, not a convenient bundle of access because integration was easier.
Then approval paths. Irreversible, externally visible, expensive, or regulated actions should require explicit review. Approval should be part of the workflow, not a manual workaround after the system is already built.
Then provenance. The system should record which source, instruction, tool output, or human decision led to the action. Provenance matters when someone asks why a record changed or why a message was sent.
Then audit and rollback. The team should be able to reconstruct the run and reverse what can be reversed. If rollback is impossible, the approval threshold should be higher.
MCP and tool servers expand the integration surface. A standard connection layer can help with integration, but it does not establish trust. Authorization, token handling, tool descriptions, user consent, and server trust still need explicit design.
Guardrails are not the whole model
Guardrails can help. They do not replace identity, authorization, audit, rollback, and approval design.
The trap is treating security as only a model-policy problem: block bad outputs, detect prompt injection, filter unsafe requests. Those controls matter, but they do not answer the system question.
If the agent can act, the security model has to describe the action.
No single control owns this risk. The design has to combine identity, least privilege, authorization, tool descriptions, approvals, logs, and recovery. Vendor guidance can help teams understand individual surfaces, but it is not a complete security model.
The AI engineering leader does not replace security. They make the agent architecture legible enough for security, platform, product, and operations to govern together.
This is also where governance becomes practical. A policy that says “use AI safely” is too broad to operate. A policy that defines which actions require human approval, which sources can be used, which logs must be retained, and which identities can call which tools gives teams something to build and audit.
The policy should also distinguish experiments from operating workflows. A prototype may run on narrow test data with no external actions. A production workflow may touch customers, contracts, source code, or money. Moving from one to the other should trigger a permission review, not only a model review.
The output of that review should be an access map. It should show the agent identity, the tools it can call, the data each tool can expose, the verbs each route permits, approval points for risky actions, and the log or rollback path. If the map is hard to draw, the system is probably harder to govern than the team thinks.
For leaders, the operating review should be plain:
- What can the agent read?
- What can it write?
- What can it execute?
- What can it send externally?
- What can it spend?
- What can it deploy?
- What can it delete?
- Which of those actions require approval?
- Which actions are logged and replayable?
- Which actions can be rolled back?
That list will expose more than a generic “is the model safe?” review.
Before expanding autonomy, ask which actions in your agent workflow are irreversible, externally visible, or expensive, and what approval path controls them. That gives the security review a shared starting point. Here are a few ways to make the answer concrete.
A few things to try
- Start with a verb inventory. Pick one agent workflow and list what it can read, write, execute, send, spend, deploy, and delete. Include the action chain, not only the first tool call. Editing a deployment file can be one step on the path to production.
- Split one broad permission. Find a capability such as generic repository or customer-record access. Separate the read path from the write path, then make the identity, scope, and audit record explicit for each.
- Add one approval boundary. Choose an irreversible, external, expensive, or regulated action and require human approval before the action is executed. The point is to expose the decision point, not to slow down harmless reads.
- Trace one action to its authority. For a recent agent action, record the identity used, source or instruction that justified it, tool called, approval received, and rollback path. A missing field exposes a gap in the access model.
- Draw the access map. Show the agent identity, data sources, tools, permitted verbs, approval gates, logs, and recovery path. Give product, platform, security, operations, and the reviewer clear ownership of their part of the map.
Which actions in your agent workflow are irreversible, externally visible, or expensive, and what approval path controls them?