AI Agent Security Assessment

An AI agent security assessment is an authorized, evidence-based review of whether a complete agent workflow can resist, detect, and contain realistic misuse.

The subject is larger than the model. An agent receives instructions and data, loads Skills, reads and writes Memory, calls tools, uses delegated authority, asks for approval, communicates with other agents, and changes external systems. A useful assessment follows that full path from initiating principal to verified effect.

The output is a decision record, not a collection of generic concerns. It states what was assessed, which controls were verified, which attack or failure paths succeeded, what remains untested, who owns each fix, and whether the reviewed release may proceed inside a stated boundary.

TL;DR

Use this AI agent security assessment process:

1. Define the decision, exact workflow, release, environment, and written authorization.
2. Inventory every identity, context source, Skill, Memory, tool, credential, runtime, integration, and agent handoff.
3. Map trust boundaries, data flows, external effects, and prohibited outcomes.
4. Turn each material risk into a control requirement and an assessment procedure.
5. Examine policies, configurations, code, records, and responsible people.
6. Test identity, authorization, context, data, tools, approvals, isolation, monitoring, and stop controls.
7. Run authorized adversarial cases in an isolated environment with synthetic data and scoped test credentials.
8. Rate findings by achieved impact, reachable authority, repeatability, detection, and recovery.
9. Block release on unmet hard requirements, not on an average score.
10. Retest fixes against the exact release and preserve the evidence.

A passing assessment does not prove that an agent is secure under every condition. It supports a bounded decision about one release, workflow, environment, user group, authority level, and evidence cutoff.

What Is an AI Agent Security Assessment?

An AI agent security assessment determines whether security controls are designed for the agent’s real authority, implemented at enforceable boundaries, operating as intended, and producing enough evidence to support a release or continued-operation decision.

That definition combines review and testing. The assessor should inspect system design and configuration, observe operating evidence, interview control owners where needed, and execute safe test cases. A control described in a policy but absent from the runtime is not implemented. A control present in code but never exercised is not verified. A control that blocks one prompt but permits the same prohibited effect through another tool path is not effective for that workflow.

NIST SP 800-53A Revision 5 provides a customizable method for assessing security and privacy controls across the system lifecycle. Its general pattern applies here: choose assessment procedures that fit the system and risk tolerance, gather evidence, and determine whether controls work as required.

This is not a certification or a claim that no vulnerability exists. Scope, access, time, test data, production restrictions, and probabilistic behavior all limit what an assessment can prove. Record those limits in the report.

Security Assessment vs. Related Reviews

These activities support each other, but they answer different questions.

Activity	Main question	Typical output
AI agent threat modeling	How could this design be manipulated or fail?	Assets, trust boundaries, threat paths, controls, and test ideas
AI agent risk management	Which risks matter, how will the organization treat them, and who accepts what remains?	Risk register, treatment, owners, monitoring, and acceptance
AI agent red teaming	Can an authorized tester defeat controls and produce a prohibited effect?	Attack evidence, findings, fixes, and replay cases
AI agent security assessment	Are the required security controls designed, implemented, tested, and evidenced for this scope?	Assessment plan, control results, findings, decision, and retest record
AI agent audit checklist	Did broader governance, security, data, operational, and lifecycle controls work over a period?	Audit plan, populations, samples, exceptions, findings, and remediation verification
AI agent readiness assessment	Is the whole workflow ready for its next operating stage?	Broader score and gate across purpose, security, reliability, operations, and ownership

A security assessment may include a threat-model review and red-team cases. It also checks controls that adversarial testing alone may not prove, such as owner eligibility, route authorization, change records, evidence retention, credential revocation, and incident duties.

Record each material finding or newly identified scenario in the AI agent risk register so treatment, acceptance, monitoring, and review continue after the assessment ends.

When to Run the Assessment

Run an assessment before an agent first reaches production when it can access sensitive data, use non-test credentials, call production tools, affect people, send external communications, write records, execute code, make decisions, or delegate work.

Trigger reassessment when a change can alter behavior, access, or impact. Examples include:

• A new model or model-provider configuration
• Changed instructions, Knowledge, Skills, or Memory policy
• A new retrieval source, data class, user group, or tenant path
• A new tool, MCP server, API operation, credential, or network destination
• Broader write access, autonomy, duration, volume, or cost limits
• A changed approval rule or authorization service
• Browser, shell, code, file, or device execution
• A new agent handoff, shared state store, or delegation path
• A new runtime, deployment environment, integration, or target system
• A security incident, near miss, control failure, or unexplained drift

Do not assess a broad label such as “support agent” when that label covers several authority levels. Reading a knowledge base, drafting a reply, issuing a credit, and closing an account are different security scopes. Assess the highest-impact path or separate them into distinct workflows.

Define Scope and Rules Before Testing

The assessment charter should state:

• Workflow and agent IDs
• Exact release, model, runtime, and configuration versions
• Business owner, technical owner, assessment lead, and decision owner
• Initiating principals, users, Groups, tenants, and service identities
• Data classes, context sources, tools, operations, and target systems
• Autonomy, time, volume, cost, and external-effect limits
• Included and excluded environments, paths, integrations, and agents
• Threats and control requirements in scope
• Evidence period and assessment cutoff
• Test accounts, fixtures, credentials, and cleanup plan
• Written authorization, safety limits, stop conditions, and contacts
• Finding severity method and release blockers
• Decision date, remediation dates, and retest rules

Active adversarial testing needs explicit authorization. Run dangerous cases in isolated systems with synthetic data, scoped test credentials, deny-by-default network access, reversible targets, resource limits, and a tested emergency stop. Do not use live secrets or customer data as test fixtures.

Production assessment should rely on safe observation, configuration review, records, and bounded checks approved for that environment. Do not turn a production review into an unplanned destructive test. If a required attack path cannot be tested safely in production, reproduce the relevant boundary in an isolated production-like environment and record the difference.

Build an Exact System Inventory

An assessment cannot cover components it does not know exist.

Inventory:

• Agent, orchestrator, models, and runtime
• System and developer instructions
• Published Knowledge and Skills
• Current Memory files, stores, writers, readers, and retention rules
• Retrieval indexes, documents, web sources, email, and tool output
• Users, service accounts, agent identities, Groups, roles, and routes
• Tools, MCP clients and servers, APIs, operations, schemas, and versions
• Credentials, token brokers, secret stores, and delegated grants
• Browsers, shells, code runners, filesystems, containers, and devices
• Queues, schedules, events, retries, caches, and persistent state
• Other agents, handoff protocols, shared stores, and trust relationships
• Approval services, policy engines, monitoring, logs, and evidence stores
• External systems where the agent can read, write, send, spend, or publish

Record the effective production set, not only the intended manifest. Compare desired configuration with runtime observation. Shadow tools, stale credentials, old routes, alternate endpoints, and forgotten schedules can create paths that the design review misses.

Map Authority, Trust Boundaries, and Effects

Draw the workflow from trigger to external outcome. Mark each place where identity, trust, data class, instruction priority, tenant, or execution environment changes.

For every action, record:

1. Who initiated the work?
2. Which agent identity acts?
3. Which user authority, agent authority, task grant, policy, and approval apply?
4. Which context and data can influence the decision?
5. Which tool and operation can create the effect?
6. Where does enforcement happen?
7. How does the system verify the result?
8. Which evidence proves the decision and effect later?

The OWASP Agentic Threats Navigator calls out reasoning, Memory, tools, identity, human oversight, and multi-agent interaction as agent attack surfaces. Use those surfaces to challenge the map, but add every domain-specific path the workflow exposes.

Sequence matters. Several individually allowed reads and writes can combine into data exfiltration, approval manipulation, privilege expansion, or an irreversible business effect. Assess complete action chains, alternate tools, retries, and delegated hops.

Turn Risks Into Assessment Procedures

A control list is not yet an assessment plan. For each material requirement, write:

• Control objective: the result the control must produce
• Assessment object: policy, configuration, code, identity, route, tool, record, activity, or person
• Method: examine, interview, observe, or test
• Procedure: the steps and safe inputs used
• Expected evidence: the record that demonstrates the result
• Pass condition: the exact behavior required
• Failure condition: the state that creates a finding or blocker
• Sample and period: which releases, runs, users, or events are covered
• Owner: who can explain and fix the control

For example, “the agent uses least privilege” is too vague. A testable requirement is: “For a user with read-only access, the agent cannot invoke a write operation through any direct, alternate, scheduled, or delegated tool path, and the denied attempt produces an authorization record tied to the run.”

NIST’s August 2026 initial public draft of the TEVV-Athlon Framework describes a flexible way to build assessments around organizational objectives and includes agentic systems in its scope. Security teams can use the same principle: choose events, tools, measures, and evidence that fit the workflow and decision instead of copying a generic benchmark.

Assess Eight Security Domains

The exact plan should follow the workflow’s risk, but these eight domains form a useful baseline.

1. Identity, authorization, and delegation

Verify that every production agent has a distinct, revocable identity and an active human Owner. Check action-time authorization against the initiating principal, sending agent, receiving agent, task grant, target policy, current approval, tenant, data scope, parameters, time, and environment.

Test read, write, propose, approve, and execute operations separately. Attempt stale grants, disabled users, suspended agents, expired approvals, replayed approvals, changed parameters, cross-tenant targets, and peer-agent delegation. Protected operations should deny without side effects when identity, policy, tenant, or approval decisions are missing, invalid, or indeterminate.

2. Context, Skills, Memory, and retrieval

Verify who may discover, read, change, publish, and route each Resource. Stable Knowledge and Skills use review and publication. Memory is live, versioned, and audited, so assess its writers, readers, scope, provenance, correction, retention, and isolation without assuming a publish gate.

Test that the server assembles the expected published Knowledge content, current Memory content, and published Skill version metadata and package digest under approved routes. Also prove that stale, archived, unauthorized, unrouted, and cross-tenant Resources stay out of that bundle. Because routing is independent of repository permission, treat each route as an authorized delivery grant and verify who approved it, target eligibility, tenant and data-class limits, and the server-side delivery record.

Use a trusted host-generated attestation bound to the request and session after insertion, or equivalent downstream session evidence, to verify that Knowledge and Memory content entered the agent session. For Skills, verify that read_skill returned or local sync installed the published package matching the advertised digest. Require invocation evidence when the assessed workflow must use that Skill, rather than merely make it available.

Challenge direct and indirect prompt injection through user input, documents, websites, email, retrieval, tool results, peer-agent messages, and Memory. Test whether untrusted data can become a privileged instruction, executable parameter, persistent state, or input to another user or tenant.

3. Data protection and privacy

Trace sensitive data into context, model calls, retrieval, tools, logs, Memory, caches, outputs, and external destinations. Verify purpose limits, minimization, tenant isolation, regional constraints, retention, deletion, redaction, encryption, and output policy.

Test authorized and unauthorized reads, joins, exports, citations, logs, and tool arguments. Include encoded, split, summarized, and multi-step exfiltration paths. A filter on the final response is weak if sensitive data can leave through a tool call, URL, log field, or another agent first.

4. Tools, MCP servers, and external actions

Verify tool ownership, source, version, operation allowlists, schema validation, parameter checks, credential scope, rate limits, idempotency, timeout, network destinations, and external outcome checks.

Treat tool descriptions and tool results as untrusted inputs. Test unauthorized operations, alternate tools that reach the same effect, malformed and oversized results, tool metadata changes, confused-deputy paths, partial failure, duplicate calls, and unsafe action sequences. A model choosing a tool does not authorize the action.

5. Approval and high-impact action integrity

Map every action that needs human or independent approval. Bind approval to the initiating principal, agent, authorization decision, action, target, material parameters, content version, approver, expiry, and a one-time nonce or bounded use count. Consume the nonce or decrement the use count atomically at execution, and use idempotency controls where the action supports them.

Test bypass, replay, transfer, stale approval, partial approval, hidden parameter changes, misleading summaries, compromised reviewers, unavailable approval services, concurrent duplicates, and retries. The execution boundary should recompute or verify the approved action rather than trust a model-written statement that approval exists.

6. Runtime, code, browser, and network isolation

For untrusted code, browser, file, or risky-tool execution, verify filesystem, process, network, credential, and tenant isolation. Check deny-by-default egress, scoped mounts, resource limits, bounded persistence, cleanup, image provenance, patching, and telemetry outside the agent’s control.

Test escape and cross-boundary attempts only in an authorized isolated environment. Verify that suspension blocks new work, contains queued and in-flight tasks, propagates to delegated agents and schedules, revokes active credentials, and produces independent evidence that authority and side effects stopped.

7. Multi-agent communication and shared state

Verify distinct identity, authenticated messages, bounded delegation, tenant isolation, replay protection, recursion limits, and safe handling of peer output. A receiving agent must not inherit more authority than the intersection of the initiating principal, sender, receiver, task grant, target policy, and current approval.

Test spoofed senders, forged observations, poisoned shared Memory, replayed tasks, circular delegation, role confusion, and cascading tool use. Peer-agent content is untrusted even when both agents belong to the same organization.

8. Monitoring, evidence, response, and recovery

Verify that operators can detect control failure, unexpected actions, data exposure, injection attempts, privilege changes, cost spikes, loops, agent cascades, and missing evidence. Alerts need owners, thresholds, response routes, and tested runbooks.

Connect run, trace, context delivery, authorization, approval, tool policy, tool call, external effect, incident, and remediation records with stable IDs. Protect evidence integrity and keep it outside the acting agent’s write authority. Test whether responders can suspend the workflow, preserve evidence, scope impact, revoke access, recover state, and confirm that harmful effects stopped.

The OWASP AI Agent Security Cheat Sheet recommends structured adversarial testing across tool misuse, privilege escalation, Memory poisoning, data exfiltration, approval bypass, multi-agent chaining, and resource exhaustion, with release gates and retained validation evidence.

Rate Control Results, Not Just Findings

Use a simple result state for every control requirement:

Result	Meaning
Not assessed	The plan did not cover the control or usable evidence was unavailable.
Not implemented	The required control is absent from the assessed scope.
Partially implemented	Some paths are covered, but a material path, identity, environment, or effect is not.
Implemented, not verified	The control appears in design or configuration, but the assessment did not produce enough test or operating evidence.
Verified for scope	Current evidence shows the control met its pass condition for the stated release, environment, sample, and period.

Do not treat “not assessed” as a pass. Record why the procedure could not run, the resulting uncertainty, and whether that uncertainty blocks the decision.

Rate each confirmed finding with the organization’s normal severity method, then add agent-specific factors:

• Achieved or plausible business and security impact
• Data, tools, systems, people, and tenants reached
• Authority required and authority gained
• Reproducibility across repeated trials
• Persistence across sessions, Memory, configuration, or agents
• Detection and time to contain
• Reversibility and recovery cost
• Availability of alternate paths to the same effect

Do not inflate a finding because the output looked surprising. Tie severity to the boundary crossed or effect reached. Do not lower severity because a probabilistic exploit failed on some runs if repeated testing shows a material success rate.

Set Hard Release Blockers

A total score can hide one missing control, so use hard blockers for unacceptable conditions.

Block production or further authority when any applicable condition remains:

• No written authorization, defined scope, active human owner, or decision owner
• Unknown production inventory, authority, data flow, or external-effect path
• Shared, broad, non-revocable, or cross-tenant agent authority
• Protected operations fail open when identity, policy, tenant, approval, or evidence services fail
• Required approval can be bypassed, replayed, transferred, or changed after approval
• Unauthorized, stale, unrouted, or cross-tenant context reaches the agent
• Prompt injection or Memory poisoning can alter privileged instructions, persist unauthorized state, disclose protected data, bypass a control, or reach an unauthorized action
• Untrusted code, browser, file, or risky-tool execution lacks verified isolation and tested containment
• Sensitive data can leave through output, tools, logs, Memory, retrieval, another agent, or an unapproved destination
• A delegated agent can exceed the initiating principal, sender, receiver, task, target, tenant, or approval boundary
• High-severity threat and failure paths lack safe representative test evidence
• Unmitigated risk remains above the approved risk appetite
• A high-severity finding or non-waivable required-control failure remains unresolved
• Material actions cannot be tied to authorization, approval, context delivery, tool policy, and external outcome evidence
• The acting agent can change or delete material assessment or production evidence
• Monitoring and incident response lack active owners or tested routes
• Suspension cannot contain new, queued, in-flight, scheduled, and delegated work; revoke active credentials; and independently verify that authority and external effects stopped
• A legal, contractual, privacy, safety, or security requirement remains unmet

A blocker may lead the team to narrow and reassess the workflow. Removing production access, using synthetic data, eliminating side effects, shrinking the user group, or moving execution into an isolated environment changes the scope. It does not make the original blocker disappear from the original scope.

Authorized residual-risk acceptance may record risk that remains within the approved appetite. It does not replace test evidence or clear unmitigated risk above appetite, an unresolved high-severity finding, or a non-waivable required-control failure.

Write a Decision-Ready Report

The report should let an authorized decision owner understand what was tested, what failed, and what the evidence supports without reading every trace.

Include:

1. Executive summary and bounded decision
2. Exact workflow, release, environment, users, tenants, data, tools, and authority
3. Assessment authorization, team, dates, and evidence cutoff
4. Architecture, data-flow, trust-boundary, and external-effect diagrams
5. Threat model and control requirements
6. Procedures run, samples used, and pass conditions
7. Control results and supporting evidence references
8. Findings with observed effect, root cause, severity, and affected scope
9. Exclusions, constraints, failed procedures, and residual uncertainty
10. Remediation owners, due dates, compensating controls, and retest rules
11. Residual-risk decisions and independent release approval
12. Final disposition: stop, redesign, isolated test, limited pilot, bounded production, or continued operation

Keep secrets, raw customer data, exploit material, and sensitive traces out of broadly shared reports. Store protected evidence under scoped access and retention rules, then link to it with stable IDs.

The security assessor should not accept residual risk or approve release merely because they produced the report. For high-impact workflows, separate implementation, evidence ownership, assessment, risk acceptance, and release authority.

Retest and Keep the Assessment Current

A fix is complete when the failed procedure passes on the intended release and related paths still work safely.

Retest should:

• Reproduce the original finding before the fix when safe
• Identify the exact code, policy, context, tool, identity, or configuration change
• Run the original case and realistic variants
• Check alternate tools and delegated paths to the same effect
• Confirm monitoring and evidence capture
• Run regression cases for adjacent controls
• Record the new release and result
• Close, downgrade, or retain the finding with a reason

Use continuous checks for controls that change often, such as context delivery, permissions, credentials, tool versions, routes, model configuration, data sources, and agent inventory. A point-in-time assessment still needs event-driven reassessment after material change.

Singapore’s updated Model AI Governance Framework for Agentic AI organizes responsible deployment around bounded risk, meaningful human accountability, technical and process controls, and informed users. A security assessment should verify the controls relevant to those duties rather than assume a framework reference proves they operate.

How Context Governance Supports the Assessment

Security tests are only reproducible when the assessor can identify the agent inputs under test.

Alignbase is an AI context control plane for governed agent inputs. Knowledge, Skills, and Memory are versioned Resources. Permissions govern who may discover, read, or change each Resource. Independent Always routes govern which Resources the server selects for each agent or Group bundle.

That separation creates concrete assessment questions:

• Who could read, change, publish, or route this Knowledge or Skill?
• Who could read or change this live Memory?
• Which published Knowledge content and current Memory content did the server assemble for the tested request?
• Which published Skill version metadata and package digests did the server advertise?
• Did read_skill return or local sync install each required package at the advertised digest?
• If the workflow requires a Skill, does invocation evidence show that it ran?
• Which Always routes caused the server to select each Resource?
• Was the route authorized for the target, tenant, and data class?
• Did unauthorized, archived, stale, or unrouted context stay out?
• Can the team reconstruct the server-side bundle from a point-in-time delivery record?
• Does a trusted host-generated attestation bound to the request and session after insertion, or equivalent downstream session evidence, confirm which Knowledge and Memory content entered the agent session?
• Does production use the same governed input and Skill package set that passed assessment?

Alignbase does not replace authorization, tool enforcement, sandboxing, data protection, monitoring, or adversarial testing. It provides the governed context and delivery evidence needed to connect those controls to the inputs that shaped agent behavior.

AI Agent Security Assessment Checklist

Before closing the assessment, confirm that the record includes:

• Written authorization, safety rules, stop conditions, and contacts
• Exact workflow, release, environment, authority, and exclusions
• Complete identity, context, data, tool, credential, runtime, and agent inventory
• Architecture, trust boundaries, data flows, and external effects
• Threat model and testable control requirements
• Assessment procedures with pass and failure conditions
• Identity, authorization, delegation, and tenant tests
• Context delivery, prompt injection, Skill, Memory, and retrieval tests
• Data protection, exfiltration, and retention checks
• Tool, MCP, approval, and external-action tests
• Runtime isolation, resource, network, and suspension tests
• Multi-agent identity, message, state, and authority tests
• Monitoring, evidence integrity, response, and recovery exercises
• Control results, findings, limitations, and residual uncertainty
• Remediation owners, deadlines, risk decisions, and retest records
• Independent decision for the exact approved scope

The assessment is useful when another reviewer can reproduce the decision from the scope, procedures, evidence, findings, and retest record. A statement that the agent “passed security” without those details is not a durable control.