Securing Agentic AI: Where MLSecOps Meets DevSecOps

The short answer

Agentic AI is a software system that uses a model to plan or select actions across tools, data sources, and workflows. Securing it requires both MLSecOps and DevSecOps: model and data provenance, evaluation, least-privilege identity, secure code, infrastructure controls, observability, and tested recovery.

The core design rule is simple: the model may propose an action, but a service with a trusted identity must decide whether that action is authorized. The OWASP guidance on excessive agency points to excessive functionality, excessive permissions, and excessive autonomy as recurring causes of impact.

What makes an agent different

A conventional model returns a response. An agent can read a ticket, retrieve documents, call an API, update a record, and continue after a failure. Its attack surface is the combination of AI-specific and conventional software risks:

The chain matters. A prompt injection may be low impact in a read-only chat and high impact when it reaches a write-capable ticket or payment tool.

MLSecOps and DevSecOps responsibilities

MLSecOps

MLSecOps manages model and data lifecycle: dataset and index provenance, model and adapter digests, evaluation corpora, prompt versions, safety tests, drift, and model rollback. It should also define how a model is loaded, where weights are stored, and which artifacts may reach production.

DevSecOps

DevSecOps protects the application and platform: identity, secrets, API authorization, container and dependency security, network policy, CI/CD gates, infrastructure-as-code, logging, and incident response. An agent inherits every weakness in these layers.

The two practices meet at the tool boundary. A model evaluation can show that an agent proposes an unauthorized call; application controls must ensure that the call is denied even when the evaluation misses it.

Least privilege for tools and identities

List every tool with its read and write effects, resource scope, identity, approval rule, and rollback method. Prefer narrow operations such as read_ticket or propose_change over a general-purpose API. Separate read and write credentials and use short-lived, audience-bound tokens.

Authorization belongs in the tool service. It should verify the caller, tenant, resource, allowed fields, business state, and approval token for every request. Prompt instructions, model confidence, or a previous tool result are not authorization evidence.

For high-impact actions, use a two-step flow: the agent prepares a typed proposal; a user or policy service approves it; the destination rechecks the authorization before commit. Log both the proposal and the decision.

Memory and retrieval boundaries

Memory is a data store with an instruction-injection risk. Partition it by tenant and user, define retention and deletion, and control who can write durable entries. Treat retrieved documents, web pages, emails, and tool responses as untrusted data. Filter by authorization before context construction and again before the result is returned.

Test whether a malicious document can persist an instruction into a later run, whether a deleted record remains in a vector index, and whether citations disclose a restricted document ID. These are data-governance and security controls, not model-style preferences.

Runtime protections

Enforce budgets outside the model:

• maximum steps, retries, tokens, duration, and concurrency;
• per-user and per-tenant cost envelopes;
• tool-specific rate and quota limits;
• network egress restrictions for agent workers;
• queue cancellation and credential revocation;
• a kill switch that stops new work and drains unsafe queued work.

When a tool fails, do not automatically retry with broader permissions or a different identity. Move the task to a safe error state and preserve the trace for review.

CI/CD security gates

An agent release should carry the model, prompt, tool, retriever, and infrastructure versions. A practical pipeline includes:

1. secret, dependency, container, and infrastructure scanning;
2. model and adapter provenance and hash verification;
3. unit tests for tool schemas and authorization;
4. regression tests for direct and indirect prompt injection;
5. cross-tenant retrieval and output-handling tests;
6. resource-limit and kill-switch tests;
7. a review of changed permissions and external connectors.

Block promotion when a high-impact tool has no negative authorization test, a model artifact is unverified, or a regression permits a previously denied action. Keep the failed scenario and trace in the build record.

Runtime detection and response

Capture a trace ID, user and service identities, model and prompt digests, retrieved item IDs, policy decisions, tool arguments, output validation, token and step counts, and final state. Redact secrets and personal data.

Alert on cross-tenant retrieval, unusual tool sequences, new credentials, repeated policy denials, tool use after cancellation, and cost or step spikes. The response playbook should cover tool disablement, credential revocation, memory/index quarantine, queue cancellation, user notification, and retest.

A compact threat-model exercise

For each business goal, write four lines:

Goal:        what the agent is expected to achieve
Data:        what it may read and from which tenant
Tools:       what it may propose or execute
Stop path:   how a human or policy service halts it

Then add an attacker-controlled input for each boundary. If the team cannot state the allowed data, action, or stop path, the system is not ready for autonomous execution.

Frequently asked questions

Is an agent safe if a human can see the final answer?

Not necessarily. A harmful tool call may have occurred before the answer was displayed. Review and authorize high-impact actions before execution, not only after the final response.

Can a general service account be used for all tools?

It should be avoided. Separate identities and scopes limit blast radius and make audit events meaningful.

Does MLSecOps replace DevSecOps?

No. Model and data controls complement standard application, cloud, and infrastructure security.

When is an agent ready for production?

When its data and tools are inventoried, permissions are enforced by destinations, resource limits and stop paths work, traces are usable, and the highest-impact scenarios pass after retest.

Related reading

• Beyond Jailbreaks: Contextual Red Teaming for Agentic AI
• Automated Red Teaming for Agentic AI Workflows
• AI Security Testing for GenAI Applications