ASAI Security ResearchIndependent public-source research
Public reviewread only

Vendor-focused standards view

CIS Critical Security Controls for CyberArk Secure AI Agents

See how CyberArk Secure AI Agents's public claims connect to security requirements and CIS Critical Security Controls references.

What this page shows

Requirements connected to CyberArk Secure AI Agents's public claims

Only requirements with strong or limited public support appear. The framework references identify what to investigate; they do not establish implementation, conformance, certification, or product effectiveness.

Versionv8.1 with 2026 AI Companion GuidesCurrent source
Related requirements11security questions in this research
Security requirements with public support13strong or limited public support
References58identifiers, clauses, safeguards, or categories

How to use this map

Framework connections help structure your evaluation

Each connection shows how a security requirement relates to this framework. Public vendor claims are shown separately, and deployed effectiveness still requires confirmation or testing.

Contributes
9
Related context
1
Closely aligned
1

Official companion guidance

Use the guide for the AI technology being assessed

These guides interpret CIS Controls v8.1 for large language model (LLM), AI agent, and Model Context Protocol (MCP) environments. They are not vendor scorecards.

LLMApplies CIS Controls v8.1 to prompts, context handling, model access, sensitive data, and LLM operations.Official guide ↗AgentApplies CIS Controls v8.1 to agent planning, tool use, delegated actions, identity, and runtime behavior.Official guide ↗MCPApplies CIS Controls v8.1 to MCP tool access, non-human identity, authorization, logging, and protocol operations.Official guide ↗

Requirement connections

From CyberArk Secure AI Agents's public claims to questions to verify

Each row starts with a security requirement that has public support, then shows the connected framework references and the next question to verify.

ContributesSpecific reference · research-team interpretation

AI usage inventory

Maintain an inventory of AI tools, services, models, agents, software as a service (SaaS) AI capabilities, data flows, and provider relationships.

Framework references
  • 2.1Establish and Maintain a Software InventoryIG1+
  • 3.8Document Data FlowsIG2+
  • 15.1Establish and Maintain an Inventory of Service ProvidersIG1+
Lifecycle

Govern · Identify · Monitor

Security requirements with public support

3 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated baseline alignment. CIS inventories software, data flows, and service providers; the AI-specific asset model comes from the linked large language model (LLM), Agent, and Model Context Protocol (MCP) companion guides.

Strong public supportUnapproved AI use discovery

Discover and monitor workforce AI tools, accounts, prompts, domains, models, users, and usage outside approved controls.

Public claims reviewed
1
Next question to verify
An unmanaged AI app used by a test user appears in discovery inventory with user, app or domain, and timestamp.
Review source claims →
Limited public supportAI-feature discovery in business applications

Inventory software as a service (SaaS) applications that embed AI features, expose enterprise data to AI capabilities, or create AI-driven data movement.

Public claims reviewed
1
Next question to verify
A software as a service (SaaS) app with an embedded AI feature appears in the software as a service (SaaS) AI inventory with app, provider, and feature context.
Review source claims →
Strong public supportApproved AI usage monitoring

Monitor approved AI workspaces, tenants, gateways, and model platforms such as ChatGPT Enterprise, Claude Enterprise, Gemini, Microsoft Copilot, Vertex AI, Elvex, or internal AI gateways.

Public claims reviewed
1
Next question to verify
Approved AI workspace activity appears with user, workspace or tenant, model or provider, and timestamp.
Review source claims →
How this could be implemented

AI asset inventory · vendor/provider inventory · AI app discovery · model/application programming interface (API)/provider catalog

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Use this for inventory/discovery claims. Do not infer control or blocking from visibility-only language. ISO 42001 excerpt: A.4.2 "identify and document relevant resources"; A.4.3 "data resources utilized"; A.4.4 "tooling resources utilized".

ContributesSpecific reference · research-team interpretation

AI usage monitoring

Monitor AI usage, user activity, prompts, responses, provider calls, runtime actions, and anomalous behavior.

Framework references
  • 8.2Collect Audit LogsIG1+
  • 8.5Collect Detailed Audit LogsIG2+
  • 8.9Centralize Audit LogsIG2+
  • 8.11Conduct Audit Log ReviewsIG2+
Lifecycle

Monitor · Detect · Operate

Security requirements with public support

3 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated baseline alignment. These safeguards establish audit-log collection, detail, centralization, and review; AI telemetry scope must still be confirmed.

Strong public supportUnapproved AI use discovery

Discover and monitor workforce AI tools, accounts, prompts, domains, models, users, and usage outside approved controls.

Public claims reviewed
1
Next question to verify
An unmanaged AI app used by a test user appears in discovery inventory with user, app or domain, and timestamp.
Review source claims →
Strong public supportApproved AI usage monitoring

Monitor approved AI workspaces, tenants, gateways, and model platforms such as ChatGPT Enterprise, Claude Enterprise, Gemini, Microsoft Copilot, Vertex AI, Elvex, or internal AI gateways.

Public claims reviewed
1
Next question to verify
Approved AI workspace activity appears with user, workspace or tenant, model or provider, and timestamp.
Review source claims →
Strong public supportAction-taking agent monitoring

Observe and govern agent plans, memory, tool calls, delegated tasks, autonomy, runtime decisions, and outcomes.

Public claims reviewed
1
Next question to verify
A test agent run captures plan, steps, tool calls, outcome, and timestamps.
Review source claims →
How this could be implemented

prompt logs · user activity · provider telemetry · agent step tracing · tool call logging

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Monitoring claims should identify what is monitored and where the telemetry comes from. ISO 42001 excerpt: 9.1 "what needs to be monitored"; A.6.2.6 "system and performance monitoring"; A.6.2.8 "event logs should be enabled".

ContributesSpecific reference · research-team interpretation

unapproved AI control

Enforce policy against unapproved AI tools or unsafe AI interactions through blocking, coaching, allowlists, or runtime controls.

Framework references
  • 2.5Allowlist Authorized SoftwareIG2+
  • 2.7Allowlist Authorized ScriptsIG3+
  • 9.3Maintain and Enforce Network-Based URL FiltersIG2+
Lifecycle

Protect · Deploy · Operate

Security requirements with public support

2 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated baseline alignment. Allowlisting and URL filtering support enforcement, but do not by themselves establish prompt-, model-, agent-, or tool-aware policy controls.

Limited public supportControls for unapproved AI use

Block, coach, redirect, or contain non-approved AI use and policy-violating AI interactions.

Public claims reviewed
1
Next question to verify
A policy blocks, coaches, redirects, or contains a test interaction with an unapproved AI destination.
Review source claims →
Limited public supportGenerative AI application security

Protect enterprise-built large language model (LLM) applications, retrieval-augmented generation (RAG) systems, prompts, application programming interfaces (APIs), model calls, tools, and production runtime behavior.

Public claims reviewed
1
Next question to verify
A test large language model (LLM) application event records prompt, application programming interface (API), model, retrieval, or tool interaction context.
Review source claims →
How this could be implemented

blocking · allowlists · browser enforcement · policy coaching · large language model (LLM) firewall · tool allowlists

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Distinguish hard blocking from warning, coaching, logging, or after-the-fact reporting. ISO 42001 excerpt: A.9.2 "processes for the responsible use"; A.9.3 "objectives to guide"; A.9.4 "intended uses".

ContributesSpecific reference · research-team interpretation

AI data protection

Prevent sensitive data exposure through prompts, responses, files, retrieval, memory, embeddings, or AI-connected workflows.

Framework references
  • 3.2Establish and Maintain a Data InventoryIG1+
  • 3.3Configure Data Access Control ListsIG1+
  • 3.8Document Data FlowsIG2+
  • 3.10Encrypt Sensitive Data in TransitIG2+
  • 3.11Encrypt Sensitive Data at RestIG2+
  • 3.13Deploy a Data Loss Prevention SolutionIG3+
  • 3.14Log Sensitive Data AccessIG3+
Lifecycle

Protect · Operate · Monitor

Security requirements with public support

3 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated baseline alignment. CIS data safeguards provide the operational baseline; AI prompt, response, retrieval, memory, and embedding coverage still requires product-specific evidence.

Limited public supportSensitive-data protection for generative AI

Detect, classify, redact, or block sensitive data in prompts, responses, files, retrieval, memory, and AI-connected workflows.

Public claims reviewed
1
Next question to verify
Sensitive prompt, response, or file test data is detected and classified during an AI interaction.
Review source claims →
Limited public supportGenerative AI application security

Protect enterprise-built large language model (LLM) applications, retrieval-augmented generation (RAG) systems, prompts, application programming interfaces (APIs), model calls, tools, and production runtime behavior.

Public claims reviewed
1
Next question to verify
A test large language model (LLM) application event records prompt, application programming interface (API), model, retrieval, or tool interaction context.
Review source claims →
Strong public supportApproved AI usage monitoring

Monitor approved AI workspaces, tenants, gateways, and model platforms such as ChatGPT Enterprise, Claude Enterprise, Gemini, Microsoft Copilot, Vertex AI, Elvex, or internal AI gateways.

Public claims reviewed
1
Next question to verify
Approved AI workspace activity appears with user, workspace or tenant, model or provider, and timestamp.
Review source claims →
How this could be implemented

data loss prevention (DLP) · redaction · sensitive data detection · output filtering · memory scoping · data-in-use protection

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Require source language that ties data protection to AI use, not generic encryption alone. ISO 42001 excerpt: A.7.3 "acquisition and selection"; A.7.4 "requirements for data quality"; A.7.5 "recording the provenance"; A.7.6 "data preparation methods".

ContributesSpecific reference · research-team interpretation

generative AI application security

Secure large language model (LLM) applications, retrieval-augmented generation (RAG) systems, prompts, tool calls, application programming interfaces (APIs), model interactions, and runtime behavior.

Framework references
  • 16.1Establish and Maintain a Secure Application Development ProcessIG2+
  • 16.2Establish and Maintain a Process to Accept and Address Software VulnerabilitiesIG2+
  • 16.6Establish and Maintain a Severity Rating System and Process for Application VulnerabilitiesIG2+
  • 16.10Apply Secure Design Principles in Application ArchitecturesIG2+
  • 16.12Implement Code-Level Security ChecksIG3+
  • 16.13Conduct Application Penetration TestingIG3+
Lifecycle

Develop · Test · Release · Deploy · Operate

Security requirements with public support

4 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated baseline alignment. CIS secure-development safeguards structure application assurance; AI-specific attack classes and runtime controls remain separate test requirements.

Limited public supportGenerative AI application security

Protect enterprise-built large language model (LLM) applications, retrieval-augmented generation (RAG) systems, prompts, application programming interfaces (APIs), model calls, tools, and production runtime behavior.

Public claims reviewed
1
Next question to verify
A test large language model (LLM) application event records prompt, application programming interface (API), model, retrieval, or tool interaction context.
Review source claims →
Limited public supportSensitive-data protection for generative AI

Detect, classify, redact, or block sensitive data in prompts, responses, files, retrieval, memory, and AI-connected workflows.

Public claims reviewed
1
Next question to verify
Sensitive prompt, response, or file test data is detected and classified during an AI interaction.
Review source claims →
Limited public supportControls for unapproved AI use

Block, coach, redirect, or contain non-approved AI use and policy-violating AI interactions.

Public claims reviewed
1
Next question to verify
A policy blocks, coaches, redirects, or contains a test interaction with an unapproved AI destination.
Review source claims →
Strong public supportAI gateway, tool-connection, and runtime controls

Mediate model, agent, tool, application programming interface (API), connector, and Model Context Protocol (MCP) traffic through an enforcement point that applies identity-aware policy, content controls, routing, rate limits, and auditable allow or deny decisions.

Public claims reviewed
1
Next question to verify
A model, agent, tool, or Model Context Protocol (MCP) request passes through a named policy enforcement point.
Review source claims →
How this could be implemented

prompt injection defense · large language model (LLM) app scanning · retrieval-augmented generation (RAG) security · guardrails · model/application interaction security

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Use for large language model (LLM) application controls. Separate from employee AI usage governance when possible. ISO 42001 excerpt: A.6.2.4 "verification and validation measures"; A.6.2.5 "deployment plan"; A.6.2.6 "ongoing operation"; A.6.2.8 "event logs".

Related contextSpecific reference · research-team interpretation

AI governance, risk, and compliance operations

Maintain accountable AI inventory, policy, risk assessments, approvals, exceptions, regulatory mappings, third-party oversight, and audit evidence across the AI lifecycle.

Framework references
  • 2.1Establish and Maintain a Software InventoryIG1+
  • 14.1Establish and Maintain a Security Awareness ProgramIG1+
  • 15.2Establish and Maintain a Service Provider Management PolicyIG2+
  • 17.1Designate Personnel to Manage Incident HandlingIG1+
Lifecycle

Govern · Identify · Assess · Approve · Monitor

Security requirements with public support

3 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated operational baseline only. CIS supports inventory, awareness, provider policy, and incident ownership, but it does not replace an AI management system or regulatory assessment workflow.

Strong public supportAI governance, risk, and compliance

Inventory AI systems and owners, translate policy and regulatory obligations into governed workflows, assess risk, manage approvals and exceptions, and retain audit evidence across the AI lifecycle.

Public claims reviewed
1
Next question to verify
A test AI system is registered with owner, intended use, risk tier, lifecycle state, and applicable obligations.
Review source claims →
Strong public supportApproved AI usage monitoring

Monitor approved AI workspaces, tenants, gateways, and model platforms such as ChatGPT Enterprise, Claude Enterprise, Gemini, Microsoft Copilot, Vertex AI, Elvex, or internal AI gateways.

Public claims reviewed
1
Next question to verify
Approved AI workspace activity appears with user, workspace or tenant, model or provider, and timestamp.
Review source claims →
Limited public supportAI-feature discovery in business applications

Inventory software as a service (SaaS) applications that embed AI features, expose enterprise data to AI capabilities, or create AI-driven data movement.

Public claims reviewed
1
Next question to verify
A software as a service (SaaS) app with an embedded AI feature appears in the software as a service (SaaS) AI inventory with app, provider, and feature context.
Review source claims →
How this could be implemented

AI system registry · risk tiering · policy workflow · regulatory mapping · approval and exception workflow · audit evidence

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Governance evidence must show accountable workflow or decision evidence, not technical inventory alone. ISO 42001 excerpt: A.9.2 "processes for the responsible use"; A.9.3 "objectives to guide"; A.10.2 "allocated between".

ContributesSpecific reference · research-team interpretation

AI assurance, red teaming, and supply-chain security

Test models, applications, retrieval-augmented generation (RAG) systems, agents, coding workflows, and AI artifacts before release and continuously thereafter, with reproducible findings and remediation gates.

Framework references
  • 16.1Establish and Maintain a Secure Application Development ProcessIG2+
  • 16.2Establish and Maintain a Process to Accept and Address Software VulnerabilitiesIG2+
  • 16.4Establish and Manage an Inventory of Third-Party Software ComponentsIG2+
  • 16.6Establish and Maintain a Severity Rating System and Process for Application VulnerabilitiesIG2+
  • 16.10Apply Secure Design Principles in Application ArchitecturesIG2+
  • 16.12Implement Code-Level Security ChecksIG3+
  • 16.13Conduct Application Penetration TestingIG3+
Lifecycle

Develop · Test · Release · Monitor

Security requirements with public support

1 requirement with public support

Companion-guide relevanceLLMAgentMCP

Project-curated baseline alignment. Secure development, component inventory, code checks, and penetration testing support assurance; AI red-team methods and model artifacts require additional evidence.

Limited public supportAI coding-agent and workstation security

Discover and govern AI coding agents, integrated development environment (IDE) assistants, command-line agents, skills, hooks, extensions, Model Context Protocol (MCP) tools, filesystem access, commands, network activity, secrets, and software-supply-chain actions on developer workstations and build environments.

Public claims reviewed
1
Next question to verify
A test coding agent and its skills, hooks, extensions, or Model Context Protocol (MCP) tools appear in an attributable inventory.
Review source claims →
How this could be implemented

AI red teaming · attack simulation · continuous evaluation · model scanning · AI bill of materials (AI-BOM) · coding-agent policy · release gate

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Keep pre-deployment testing, artifact integrity, and coding-agent controls distinguishable from runtime blocking. ISO 42001 excerpt: A.6.2.4 "verification and validation measures"; A.6.2.5 "deployment plan"; A.6.2.6 "ongoing operation".

Closely alignedSpecific reference · research-team interpretation

Third-party and software as a service (SaaS) AI risk

Understand and monitor AI risk introduced by external software as a service (SaaS), AI providers, embedded AI features, and supplier services.

Framework references
  • 15.1Establish and Maintain an Inventory of Service ProvidersIG1+
  • 15.2Establish and Maintain a Service Provider Management PolicyIG2+
  • 15.3Classify Service ProvidersIG2+
  • 15.4Ensure Service Provider Contracts Include Security RequirementsIG2+
  • 15.5Assess Service ProvidersIG3+
  • 15.6Monitor Service ProvidersIG3+
  • 15.7Securely Decommission Service ProvidersIG3+
Lifecycle

Govern · Identify · Detect

Security requirements with public support

2 requirements with public support

Companion-guide relevanceLLMAgentMCP

Project-curated alignment to the full CIS service-provider lifecycle. AI-specific provider scope and evidence expectations come from this project's normalized requirement and the companion guides.

Limited public supportAI-feature discovery in business applications

Inventory software as a service (SaaS) applications that embed AI features, expose enterprise data to AI capabilities, or create AI-driven data movement.

Public claims reviewed
1
Next question to verify
A software as a service (SaaS) app with an embedded AI feature appears in the software as a service (SaaS) AI inventory with app, provider, and feature context.
Review source claims →
Strong public supportUnapproved AI use discovery

Discover and monitor workforce AI tools, accounts, prompts, domains, models, users, and usage outside approved controls.

Public claims reviewed
1
Next question to verify
An unmanaged AI app used by a test user appears in discovery inventory with user, app or domain, and timestamp.
Review source claims →
How this could be implemented

third-party AI inventory · supplier AI service monitoring · software as a service (SaaS) AI detection · provider activity monitoring

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Third-party sources are only allowed in the project if one source class covers at least 80 percent of vendors. ISO 42001 excerpt: A.10.2 "allocated between"; A.10.3 "provided by suppliers aligns".

ContributesSpecific reference · research-team interpretation

Agentic telemetry and behavior monitoring

Observe agent steps, plans, goals, memory, delegation, tool use, and anomalies during runtime.

Framework references
  • 8.2Collect Audit LogsIG1+
  • 8.5Collect Detailed Audit LogsIG2+
  • 8.9Centralize Audit LogsIG2+
  • 8.11Conduct Audit Log ReviewsIG2+
Lifecycle

Operate · Monitor · Detect

Security requirements with public support

3 requirements with public support

Companion-guide relevanceAgentMCP

Project-curated baseline alignment. Audit-log safeguards support telemetry operations; the Agent and Model Context Protocol (MCP) guides supply the relevant AI runtime interpretation.

Strong public supportAction-taking agent monitoring

Observe and govern agent plans, memory, tool calls, delegated tasks, autonomy, runtime decisions, and outcomes.

Public claims reviewed
1
Next question to verify
A test agent run captures plan, steps, tool calls, outcome, and timestamps.
Review source claims →
Strong public supportAgent-to-agent communication security

Authorize, log, and control agent-to-agent, agent-to-tool, Model Context Protocol (MCP), connector, and tool-chain handoffs.

Public claims reviewed
1
Next question to verify
An agent, tool, connector, or Model Context Protocol (MCP) handoff logs source identity, destination, and authorization decision.
Review source claims →
Strong public supportNon-human identity and service-account security

Inventory, least privilege, credential hygiene, monitoring, and lifecycle management for non-human identities, workloads, service accounts, application programming interface (API) keys, and machine credentials.

Public claims reviewed
1
Next question to verify
A test service account, agent identity, or non-human identity appears in inventory with owner and privileges.
Review source claims →
How this could be implemented

agent traces · goal drift detection · memory mutation monitoring · tool execution logs · anomalous delegation

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Require explicit agent language. Generic chatbot monitoring is not enough. ISO 42001 excerpt: 9.1 "monitoring and measuring"; A.6.2.6 "system and performance monitoring"; A.6.2.8 "event logs should be enabled".

ContributesSpecific reference · research-team interpretation

Agent-to-agent and tool communication security

Secure trust, authorization, message flows, tool access, and communication between agents, tools, application programming interfaces (APIs), and external services.

Framework references
  • 5.1Establish and Maintain an Inventory of AccountsIG1+
  • 6.1Establish an Access Granting ProcessIG1+
  • 6.2Establish an Access Revoking ProcessIG1+
  • 6.5Require MFA for Administrative AccessIG1+
  • 6.8Define and Maintain Role-Based Access ControlIG3+
  • 8.2Collect Audit LogsIG1+
Lifecycle

Identify · Protect · Deploy · Monitor

Security requirements with public support

4 requirements with public support

Companion-guide relevanceAgentMCP

Project-curated baseline alignment. Account, access, administrative MFA, role, and log safeguards support agent-to-tool trust; protocol-specific authorization still requires Model Context Protocol (MCP) and product evidence.

Strong public supportAgent-to-agent communication security

Authorize, log, and control agent-to-agent, agent-to-tool, Model Context Protocol (MCP), connector, and tool-chain handoffs.

Public claims reviewed
1
Next question to verify
An agent, tool, connector, or Model Context Protocol (MCP) handoff logs source identity, destination, and authorization decision.
Review source claims →
Strong public supportAction-taking agent monitoring

Observe and govern agent plans, memory, tool calls, delegated tasks, autonomy, runtime decisions, and outcomes.

Public claims reviewed
1
Next question to verify
A test agent run captures plan, steps, tool calls, outcome, and timestamps.
Review source claims →
Limited public supportGenerative AI application security

Protect enterprise-built large language model (LLM) applications, retrieval-augmented generation (RAG) systems, prompts, application programming interfaces (APIs), model calls, tools, and production runtime behavior.

Public claims reviewed
1
Next question to verify
A test large language model (LLM) application event records prompt, application programming interface (API), model, retrieval, or tool interaction context.
Review source claims →
Strong public supportAI gateway, tool-connection, and runtime controls

Mediate model, agent, tool, application programming interface (API), connector, and Model Context Protocol (MCP) traffic through an enforcement point that applies identity-aware policy, content controls, routing, rate limits, and auditable allow or deny decisions.

Public claims reviewed
1
Next question to verify
A model, agent, tool, or Model Context Protocol (MCP) request passes through a named policy enforcement point.
Review source claims →
How this could be implemented

agent-to-agent (A2A) registry · mutual TLS (mTLS) · inter-agent authorization · connector contracts · tool schemas · message logs

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Do not map agent-to-agent (A2A) unless a source mentions agents, tools, connectors, protocols, or machine-to-machine authorization. ISO 42001 has no direct agent-to-agent (A2A) security control. ISO 42001 excerpt: A.6.2.4 "verification and validation measures"; A.6.2.8 "event logs"; A.10.2 "allocated between".

ContributesSpecific reference · research-team interpretation

non-human identity (NHI) and AI-agent identity governance

Manage identities, credentials, privileges, secrets, service accounts, and lifecycle for AI agents and other non-human identities.

Framework references
  • 5.1Establish and Maintain an Inventory of AccountsIG1+
  • 5.4Restrict Administrator Privileges to Dedicated Administrator AccountsIG1+
  • 6.1Establish an Access Granting ProcessIG1+
  • 6.2Establish an Access Revoking ProcessIG1+
  • 6.3Require MFA for Externally-Exposed ApplicationsIG1+
  • 6.5Require MFA for Administrative AccessIG1+
  • 6.8Define and Maintain Role-Based Access ControlIG3+
Lifecycle

Govern · Protect · Deploy · Operate

Security requirements with public support

4 requirements with public support

Companion-guide relevanceAgentMCP

Project-curated baseline alignment. CIS account and access safeguards apply to non-human identities when implemented that way; the Agent and Model Context Protocol (MCP) guides provide the explicit AI context.

Strong public supportNon-human identity and service-account security

Inventory, least privilege, credential hygiene, monitoring, and lifecycle management for non-human identities, workloads, service accounts, application programming interface (API) keys, and machine credentials.

Public claims reviewed
1
Next question to verify
A test service account, agent identity, or non-human identity appears in inventory with owner and privileges.
Review source claims →
Strong public supportAI agent identity and permissions

Register AI agents as accountable identities, bind them to owners and delegating users, authorize task- and tool-level access, issue short-lived credentials, review access, and revoke or suspend agent authority.

Public claims reviewed
1
Next question to verify
A test agent is registered with a unique identity, accountable owner, purpose, and permitted resources.
Review source claims →
Strong public supportAgent-to-agent communication security

Authorize, log, and control agent-to-agent, agent-to-tool, Model Context Protocol (MCP), connector, and tool-chain handoffs.

Public claims reviewed
1
Next question to verify
An agent, tool, connector, or Model Context Protocol (MCP) handoff logs source identity, destination, and authorization decision.
Review source claims →
Limited public supportAI-feature discovery in business applications

Inventory software as a service (SaaS) applications that embed AI features, expose enterprise data to AI capabilities, or create AI-driven data movement.

Public claims reviewed
1
Next question to verify
A software as a service (SaaS) app with an embedded AI feature appears in the software as a service (SaaS) AI inventory with app, provider, and feature context.
Review source claims →
How this could be implemented

non-human identity (NHI) inventory · AI service accounts · least privilege · credential rotation · scoped tokens · privilege review

What public claims cannot prove

Public claims identify what to verify. They do not confirm control implementation or deployed effectiveness.

Why this connection is included

Separate AI-agent identity claims from generic human identity and access management (IAM) unless the vendor explicitly spans service accounts or NHIs. ISO 42001 has no direct non-human identity (NHI) identity control. ISO 42001 excerpt: A.4.2 "relevant resources"; A.10.2 "responsibilities".

This page organizes research. Audit conclusions, certification assessments, control implementation statements, and vendor endorsements require separate evidence.