Secure enterprise AI agents: architecture, access and human control

What makes an AI agent different?

A conventional assistant provides information. An agent can plan steps, select tools, read and write to systems and continue until it reaches a goal. That expands the value and the radius of a potential failure.

The central architecture question is not how intelligent the model is. It is what authority the system has, under which conditions, and how every action can be demonstrated later.

1. Identity before intelligence

Every agent runtime needs a clear workload identity. Do not use shared administrator keys or human credentials. Separate identity by environment and use case and prefer short-lived tokens.

When the agent acts for a user, preserve user context and verify that an action is allowed for both the agent and the person. This prevents AI becoming a route around the existing access model.

2. Least privilege at tool and action level

CRM access should not imply permission to read and modify every record. Define narrow tools such as create draft opportunity, retrieve order status or add internal note instead of exposing a universal database or API interface.

Validate arguments outside the model. Allowed fields, values, recipients and business rules belong in a deterministic policy layer.

3. A tool gateway between the model and systems

The model should not communicate directly with production systems. A controlled gateway can enforce authentication, authorisation, schema validation, rate limits, data filtering, idempotency and audit logging.

This layer allows the model to change without rebuilding every integration and makes the trust boundary visible to security and operations teams.

4. Risk-based human approval

Actions do not require equal control. Reading a public procedure, preparing a draft and sending a payment have different risk. Create a policy matrix based on impact, value, sensitivity, confidence and reversibility.

Approval should show what will happen, why the agent proposes it, which data it used and what will change. An approve button without context is ceremony rather than control.

5. Prompt injection and untrusted input

Documents, email and web content can contain instructions that attempt to redirect the agent. Treat retrieved content as data, not trusted commands. Constrain tools, filter context and isolate instructions from content.

No single prompt solves the problem. Protection combines architecture, permissions, content handling, policy enforcement, evaluation and a limited blast radius.

6. Logging, observability and privacy

For every task, you should be able to reconstruct who started it, what context was used, which decision was taken, which tools were called, what they returned and who approved. Carry one correlation ID across the workflow.

Do not indiscriminately retain every prompt and document. Apply redaction, retention, role-based access and separation between operational telemetry and sensitive content.

7. Evaluation and safe change management

Test more than response quality. Cover permitted and prohibited actions, missing data, prompt injection, tool failure, timeouts and conflicting instructions. Include adversarial cases.

Version prompts, policies, tools, retrieval and models. Every change should pass evaluation and staged rollout. Provide a kill switch and a quick return to a previous version.

Minimum production checklist

• Separate workload identity and least-privilege permissions.
• An allowlist of narrow, schema-validated tools.
• A policy engine outside the model.
• Human approval for high-risk or irreversible actions.
• End-to-end audit trail with a correlation ID.
• Evaluation set covering abuse and failure scenarios.
• Cost, rate and concurrency limits.
• Monitoring, alerts, rollback and a kill switch.
• Data retention, redaction and incident response process.