Date: 10 November 2026

Moving Beyond Chatbots: Securing AI Agents That Actually Modify Code and Execute Workflows

Executive Summary

AI agents create a different security problem from chatbots. A chatbot mainly returns information. An agent can read repositories, change files, open pull requests, run commands, deploy infrastructure, and update business systems. A flawed response is inconvenient. A flawed tool call can become an incident.

The security decision is clear: treat an agent as a software actor with constrained authority, not as a trusted employee with unrestricted access. Assign it a distinct identity, authorize every meaningful action, enforce policy outside the model, record decisions and results, and require human approval where the impact cannot be safely reversed.

Contents

• Architecture and Trust Boundaries
• Threat Model
• Controls That Matter
• Implementation Pattern
• Risks and Mitigations
• Deployment Checklist
• Frequently Asked Questions

Architecture and Trust Boundaries

An agent system usually contains five logical components:

• Interaction layer: receives a user request, event, ticket, or scheduled task.
• Reasoning layer: selects a plan and proposes tool calls.
• Policy decision point: evaluates whether each proposed action is allowed.
• Tool gateway: invokes repositories, shells, APIs, cloud services, or internal systems.
• Target systems: contain the code, data, credentials, and production resources being changed.

These components should not share one implicit trust zone. The model may be useful for planning, but it should not be the final authority on access. The tool gateway should be the enforcement boundary. It receives a structured request, authenticates the calling agent, evaluates policy, applies limits, invokes the target system, and returns a controlled result.

There are several trust boundaries to identify:

• The boundary between an untrusted prompt and the agent's internal instructions.
• The boundary between model-generated arguments and tool execution.
• The boundary between the agent runtime and stored credentials.
• The boundary between a development environment and production systems.
• The boundary between tool output and the next reasoning step.

Tool output deserves particular attention. A repository file, ticket, web page, or command result can contain instructions designed to manipulate the agent. Treat tool output as data, not as a new policy source. The agent may quote or analyze it, but it should not gain authority merely because the text came from an internal system.

Threat Model for Code-Modifying Agents

The threat model should cover both malicious users and accidental behavior. A legitimate user can submit an ambiguous request. A compromised account can ask for a dangerous change. A poisoned issue, dependency, or repository file can attempt prompt injection. A model can also select an unsafe tool or construct incorrect arguments without any malicious input.

Prompt and Context Attacks

Indirect prompt injection occurs when instructions are embedded in content the agent reads. Examples include a comment in a source file that says to ignore security rules, an issue containing a request to disclose environment variables, or a document that asks the agent to upload files to an external endpoint.

Defenses include separating instructions from retrieved content, labeling provenance, limiting the content available to each task, and requiring policy checks for sensitive actions. The agent should never be allowed to convert arbitrary text into permission.

Excessive Authority

An agent that can read every repository, assume a production role, and execute arbitrary shell commands has a large blast radius. A successful attack is not required. A mistaken plan is enough.

Use task-specific identities and narrow scopes. A code-review agent may need read access to one repository and permission to write review comments. It may not need a deployment role. A patch agent may create a branch but not merge directly into a protected branch.

Confused Deputy Behavior

A confused deputy occurs when the agent uses its own authority to perform an action that the requesting user could not perform. The system must evaluate both the agent identity and the user's authority. “The agent is allowed” is not sufficient if the user is not allowed to request the operation.

Workflow and Replay Abuse

Agents often run asynchronously. Requests can be duplicated, retried, or resumed after a partial failure. An operation that was safe once may be harmful when repeated, such as creating duplicate tickets, rotating a credential twice, or applying a migration after the expected state has changed.

Use request identifiers, idempotency keys, state checks, expiration times, and explicit workflow checkpoints. Treat retries as a security concern, not only a reliability concern.

Authentication, Authorization, Policy, and Auditability

These controls solve different problems and should not be collapsed into one token check.

• Authentication answers: “Which principal is making this request?” The principal may be an agent runtime, a user, a workflow, or a service account.
• Authorization answers: “Is this principal allowed to perform this action on this resource?” It should consider the user, agent, resource, operation, environment, and context.
• Policy enforcement answers: “What conditions must be satisfied before the action can execute?” Conditions may include approval, branch status, data classification, command restrictions, rate limits, or a required change window.
• Auditability answers: “What happened, who requested it, what was decided, and what was the result?” Audit records support investigation and control testing, but they do not prevent an unauthorized action by themselves.

For high-impact actions, authorization should be evaluated immediately before execution. Do not authorize a plan once and assume every later tool call is covered. The target resource, arguments, environment, and user intent can change during a long run.

Implementation Pattern

The following is an illustrative policy flow. It is not a vendor-specific standard.

function executeToolCall(request, context):
    principal = authenticateAgent(request.agentCredential)
    user = authenticateUser(context.userCredential)

    if not principal or not user:
        return deny("authentication_failed")

    if not authorization.allows(
        user=user,
        agent=principal,
        action=request.action,
        resource=request.resource
    ):
        return deny("authorization_failed")

    decision = policy.evaluate({
        action: request.action,
        resource: request.resource,
        arguments: request.arguments,
        environment: context.environment,
        user: user,
        agent: principal,
        requestId: context.requestId
    })

    audit.record("policy_decision", decision)

    if decision.status == "deny":
        return deny(decision.reason)

    if decision.status == "approval_required":
        return pauseForApproval(decision.approvalId)

    if not safetyChecks.pass(request):
        return deny("safety_check_failed")

    result = tool.invoke(request, timeout=policy.timeoutFor(request.action))
    audit.record("tool_result", redact(result))

    return result

In practice, the policy layer should work with structured actions rather than arbitrary natural-language commands. “Create pull request for repository X from branch A to branch B” is easier to validate than “do whatever is needed to ship this fix.”

Shell access requires special handling. Prefer purpose-built tools such as run_tests, read_file, and create_branch over a general shell. If a shell is unavoidable, use an isolated workspace, an allowlist of commands, resource limits, network restrictions, a non-privileged operating-system user, and a short-lived credential set. Capture the exact command, working directory, environment classification, exit code, and output summary.

Secrets should not be placed in prompts or model-visible context unless there is a documented reason. Use short-lived credentials retrieved at execution time. Redact tokens, private keys, session cookies, and sensitive personal data from logs and tool results. Redaction must happen before data reaches the model as well as before it reaches an audit store.

Human approval should be tied to a precise action, not a vague plan. The approval record should show the target, proposed diff or command, affected environment, requester, policy reason, expiration, and approver. If the agent changes the action after approval, require a new decision.

Risks and Mitigations

Risk	Typical failure	Mitigation
Prompt injection	Repository content changes the agent's instructions	Separate trusted instructions from retrieved data and enforce policy at the tool gateway
Excessive privilege	One agent can modify code and production infrastructure	Use separate identities, narrow scopes, environment separation, and short-lived credentials
Confused deputy	The agent performs an action the user could not perform	Check both user authority and agent authority for every sensitive operation
Unsafe command execution	Generated shell commands delete files or exfiltrate data	Prefer fixed-function tools; otherwise isolate, restrict, time-limit, and inspect commands
Approval drift	The agent executes a materially different action after approval	Bind approval to immutable action details, hashes, targets, and an expiration time
Weak audit trail	Logs show an outcome but not the decision path	Record identities, inputs, policy decisions, approvals, tool calls, results, and correlation IDs

Deployment Checklist

• Define each agent's business purpose and maximum permitted impact.
• Assign every agent a distinct identity. Do not share a human administrator credential.
• Map each tool to explicit actions, resources, scopes, and environments.
• Place authorization and policy enforcement outside the model.
• Pass the requesting user's identity and permissions into the decision.
• Use short-lived credentials and keep secrets out of prompts and model context.
• Prefer structured tools over arbitrary shell execution.
• Isolate workspaces and restrict network access for code-running tasks.
• Require approval for production changes, protected-branch merges, destructive operations, and sensitive data access.
• Make approvals specific, reviewable, expiring, and bound to the approved action.
• Implement idempotency, replay protection, timeouts, and failure recovery.
• Log denied actions as well as successful actions.
• Redact secrets before storing logs or returning tool output to the model.
• Test prompt injection, privilege escalation, confused deputy behavior, and partial failures before release.
• Define an emergency disable mechanism that can stop new tool calls without deleting evidence.

Frequently Asked Questions

Should an AI agent have its own identity?

Yes. A distinct identity makes scope, ownership, credential rotation, and investigation clearer. It does not replace the requesting user's identity. Sensitive decisions commonly need both identities.

Can a model decide whether an action is safe?

A model can propose a plan or identify risks, but it should not be the sole enforcement mechanism. Deterministic checks should enforce permissions, target restrictions, command rules, approvals, and limits.

Is read-only access always safe?

No. Read access can expose credentials, source code, personal data, or business-sensitive information. It can also give an attacker the context needed for a later attack. Classify data and scope reads as carefully as writes.

When is human approval required?

Use approval when an action is high impact, difficult to reverse, crosses an environment boundary, accesses sensitive data, or changes a security control. The threshold should be based on impact and reversibility, not on whether a model was involved.

What should be logged?

Record the request identifier, user and agent identities, selected tool, target resource, validated arguments, policy decision, approval details, execution result, and timestamps. Protect the log itself and avoid storing secrets or unnecessary sensitive content.

How should teams test agents?

Test normal workflows and adversarial ones. Include injected instructions in files, unauthorized resource requests, malformed arguments, expired approvals, duplicate events, tool outages, unexpected output, and attempts to move from development into production.

Can existing application security controls protect agents?

They provide a foundation, but agent workflows add model-generated plans, tool selection, indirect instructions, and asynchronous execution. Extend existing identity, authorization, logging, and change-control systems to cover those new decision points.

An agent becomes safer when its authority is explicit, narrow, observable, and interruptible. The model can plan. The surrounding system must decide what is allowed to happen.

Use AXEC for governed AI-agent security and schedule a 30-minute meeting to discuss your agentic workflow controls.