Security questionnaires now demand evidence of agent actions

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Skyrelis's blog post: Security questionnaires for AI agents are shifting from intent statements to evidence-based checks on actions, approvals, tenant separation and scoped access.

Why it matters: This matters because procurement, audit and operational governance now hinge on records that show what an agent did, why it was allowed and what it could reach.

Context

AI agents are now being assessed less like software features and more like governed identities with observable actions, permissions and decision records. That changes the burden of proof in security reviews: buyers want evidence they can inspect, not statements about how the system is meant to behave.

The central gap is not whether an agent can do useful work, but whether its behaviour is reviewable, attributable and bounded across tenants and approval paths. AI agent observability and incident response becomes the natural foundation for that shift.

Key questions

Q: Where should AI agent audit logs be stored for security review?

A: Store them at the control point that already sees the request, the identity, and the policy decision, such as a gateway or central log sink. That makes correlation easier, reduces format drift across servers, and gives security teams one durable source of truth for investigations.

Q: Why do customer AI agents complicate tenant isolation?

A: Customer agents often operate on behalf of a user while sharing infrastructure across many customers. If scopes are not bound to the tenant and session, one agent instance can expose another customer’s data. Tenant isolation must therefore be enforced at token issuance and continuously checked during execution.

Q: How should teams control AI agent access to downstream tools?

A: Teams should treat agent access as a bounded runtime grant, not a generic application permission. Each tool call should be covered by explicit policy, monitored for scope drift, and revocable without depending on a human to notice the problem later. If the agent can chain actions across systems, the control boundary must exist before the chain starts.

Q: What should high-risk AI agent actions require before execution?

A: High-risk AI agent actions should require rule-triggered approval from a human approver before execution, especially for money movement, privilege changes, data deletion, or external communication. The control should enforce a clear policy, log the approving identity, action scope, and timestamp, and block the agent until approval is granted or the request expires.

Technical breakdown

Why action-level logs matter more than prompts

Prompt and response transcripts describe conversation, not control. For agent governance, the actionable unit is the tool call or API action because that is what reaches customer systems, changes state, or triggers downstream workflow. An action-level log should bind the agent version, requesting user or tenant, tool invoked, parameters used, data touched, decision outcome, and any approval step. Without that structure, a security review cannot reconstruct behaviour after the fact or prove that a specific action was permitted under a specific rule.

Practical implication: Record each agent action with enough context to replay the decision path during audit or incident review.

How tenant isolation changes the evidence model

In multi-tenant agent systems, the question is not only whether customers are separated in storage, but whether policy evaluation and logs remain separable at runtime. Shared prompts with tenant-specific instructions create weak boundaries because one tenant's text sits alongside another tenant's rules. A stronger model evaluates every action in tenant context, keeps enforcement distinct per tenant, and produces logs that can be filtered and exported without cross-tenant bleed. That separation is what turns isolation from a claim into evidence. See the Agentic AI Security Policy Template.

Practical implication: Prove tenant separation with runtime policy scoping and logs that can be examined per customer without ambiguity.

What reviewer questions reveal about agent privilege boundaries

Security questionnaires are effectively asking whether the agent has a bounded identity footprint. They want to know which tools, APIs and data sources the agent can reach, how access is limited by default, and whether high-risk actions require a separate approval path. The deeper issue is least privilege for a non-human actor that may operate across multiple systems. If access is defined only in prompt language, the boundary is advisory rather than enforced. See the AI Agent Identity Security Buyer's Guide.

Practical implication: Map every reachable tool and data source to an enforceable access model outside the agent prompt.

NHI Mgmt Group analysis

Evidence is becoming the control plane for AI agent assurance. Buyers are no longer satisfied with a statement that an agent is secure or well governed. They want artifacts they can open, replay and show to their own auditors, because that is what converts an abstract trust claim into a defensible control. The practical shift is toward runtime records, approval trails and scoped policy evidence, not narrative assurances.

The agent security review is now a governance test, not a product questionnaire. The six questions in these reviews map directly to attribution, segregation, authorisation, approval, access scope and policy portability. That makes the buying process a proxy for enterprise control design, and it raises the bar for any team that cannot produce independent evidence on demand.

Auditability, not explanation, is the requirement that matters most. Reviewers do not need the model's inner reasoning if they can see the rule that matched, the action that was taken and the approval that authorised it. This is a useful distinction for governance teams: the requirement is reproducible decision evidence, not post hoc narrative.

Tenant-separated policy is the named concept this review pattern exposes. Multi-tenant agent systems fail trust review when one customer's policy or data can influence another customer's behaviour, even indirectly through shared prompts or shared logs. That boundary problem is now a procurement concern as much as an architecture concern, because reviewers want proof that one tenant cannot alter another tenant's agent path.

Least privilege for agents is being judged by reachable systems, not declared intent. If a team cannot inventory the tools, APIs and data sources an agent can touch, least privilege remains a slogan. The control question is whether access is enforced outside the prompt and whether high-risk actions are gated before execution, which is where the governance burden now sits.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Governance programmes are moving toward proof-first assurance for AI agents, where the decisive question is whether each action can be evidenced, replayed and attributed after the fact. That favours control layers that sit outside the agent and produce records reviewers can inspect without trusting the model's own output.

Tenant-separated policy: multi-tenant agent systems need separable enforcement and separable logs, because shared prompts or shared instructions blur accountability across customers. A buyer's review now tests whether one tenant can change another tenant's behavioural boundary, not just whether data stores are isolated.

The pressure is also shifting access governance upstream: least privilege has to be demonstrated at issuance time, because a reviewer will not accept a prompt as a restriction and a future audit cannot reconstruct an unbounded action path. That makes runtime policy, approval records and tool inventories the practical evidence layer for agent governance.

For practitioners

• Build action-level audit records Log each tool call with agent version, user or tenant context, parameters, touched data, decision outcome and any approval step.
• Separate tenant policy enforcement Evaluate every agent action in tenant context and keep logs separable so one customer's rules never influence another's behaviour.
• Inventory reachable tools and data sources Maintain a current list of every API, workflow and dataset the agent can reach, with default-deny access until explicitly granted.
• Gate high-risk actions with approval records Define which actions need human approval, record who approved or denied them, and keep the decision trail outside the agent itself.
• Version customer-configurable policy changes Allow compliance-related rule changes without code redeployment and preserve the version history that shows which policy was active when.

Key takeaways

• AI agent questionnaires are now measuring whether behaviour is observable, attributable and bounded, not whether the vendor says the system is secure.
• The central evidence gap is that prompts do not prove control, while action records, tenant-scoped policy and approval trails do.
• Identity governance for agents is moving toward runtime evidence, which means access scope and decision records must be inspectable before auditors ask for them.

Related NHI Mgmt Group resources: AI Agent Observability, Audit and Incident Response Guide · Agentic AI Security Policy Template · AI Agent Identity Security Buyer's Guide · Red Teaming AI Agents for Identity Abuse

Key terms

• Action-Level Audit Log: An action-level audit log is a record of each individual action an AI agent or other system performs. It captures the actor, action, target, time, and outcome, so administrators can trace delegated behaviour, investigate abuse, and support revocation or replay analysis.
• Approval Record: An approval record is the stored evidence that a specific request was authorised before it was carried out. It usually includes the approver’s identity, what was approved, when approval happened, and any conditions or expiry, which helps enforce accountability and controlled delegation.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Tenant-Scoped Policy: Tenant-scoped policy restricts authorization rules to a specific customer boundary or organisation context. It allows one SaaS platform to support different roles, permissions, and resource visibility per tenant without exposing those rules to other tenants or duplicating the entire policy model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.