에이전트형 AI를 위한 OWASP Top 10(2025) 기반 보안 평가. 프롬프트 인젝션 탐지, 도구 오염(tool poisoning) 점검, 과도한 에이전시 평가 및 데이터 유출 분석.
에이전트형 AI를 위한 OWASP Top 10(2025년 발표)은 작업을 수행하고, 도구를 사용하며, 자율적으로 운영되는 AI 에이전트에 대한 가장 중요한 10가지 보안 위험을 정의합니다. 조직이 MCP 서버, LangChain 에이전트 및 자율 AI 워크플로우를 배포함에 따라, 이러한 시스템은 기존의 AppSec 테스트로는 다룰 수 없는 공격 벡터에 직면하게 됩니다.
프롬프트 인젝션, 도구 오염, 과도한 에이전시, 교차 컨텍스트 데이터 유출은 이론적인 문제가 아니라 실제로 악용되고 있는 위협입니다. CISO와 보안 팀은 OWASP 분류에 따라 에이전트형 AI 배포를 평가할 구조화된 방법이 필요합니다. 이 MCP는 귀하의 에이전트 아키텍처를 10가지 모든 위험 범주에 대해 평가하고 실행 가능한 결과를 생성합니다.
Related MCP server: Agent Delegation MCP
pip install owasp-agentic-mcp도구 | OWASP 참조 | 기능 |
| 10가지 위험 전체 | 에이전트형 AI를 위한 OWASP Top 10 기반 전체 보안 상태 평가 |
| 위험 A01 | 에이전트 입력에서 프롬프트 인젝션 공격 벡터 탐지 |
| 위험 A02 | 도구 정의 및 MCP 설정의 오염 위험 평가 |
| 위험 A03 | 에이전트가 필요한 것보다 많은 권한을 가지고 있는지 평가 |
| 위험 A06 | 에이전트 워크플로우 내 교차 컨텍스트 데이터 유출 경로 식별 |
Prompt: "Assess the security of our customer support AI agent.
It has access to 12 MCP tools including database queries, email
sending, and file system access. It operates on user prompts
with no input sanitisation."
Result: Assessment across all 10 OWASP Agentic AI risks with critical
findings: A01 prompt injection (no input sanitisation on user prompts),
A02 tool poisoning (3 MCP tools loaded without integrity checks),
A03 excessive agency (file system + email + database = over-privileged),
A06 data leakage (database query results passed through to email tool
without redaction). Remediation priorities and control recommendations
provided for each finding.등급 | 가격 | 포함 사항 |
무료 | £0 | 일일 10회 호출 — 에이전트 보안 평가 |
Pro | £199/월 | 무제한 + HMAC 서명 인증 + URL 검증 |
Enterprise | £1,499/월 | 멀티 테넌트 + 공동 브랜드 보고서 + 웹훅 |
모든 Pro/Enterprise 감사는 암호화 서명된 인증서를 생성합니다:
POST https://meok-attestation-api.vercel.app/sign
GET https://meok-attestation-api.vercel.app/verify/{cert_id}Zero-dep 검증기: pip install meok-attestation-verify
웹사이트: meok.ai
모든 MCP 서버: meok.ai/labs/mcp/servers
기업 지원: nicholas@csoai.org
MIT
Full OWASP Agentic AI Top 10 security assessment.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: agent_name (str): The agent name to analyze or process. has_input_validation (bool): The has input validation to analyze or process. has_output_filtering (bool): The has output filtering to analyze or process. has_tool_allowlist (bool): The has tool allowlist to analyze or process. has_least_privilege (bool): The has least privilege to analyze or process. has_context_isolation (bool): The has context isolation to analyze or process. has_action_logging (bool): The has action logging to analyze or process. has_auth_between_agents (bool): The has auth between agents to analyze or process. has_resource_limits (bool): The has resource limits to analyze or process. has_dependency_scanning (bool): The has dependency scanning to analyze or process. has_alignment_testing (bool): The has alignment testing to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| has_input_validation | No | ||
| has_output_filtering | No | ||
| has_tool_allowlist | No | ||
| has_least_privilege | No | ||
| has_context_isolation | No | ||
| has_action_logging | No | ||
| has_auth_between_agents | No | ||
| has_resource_limits | No | ||
| has_dependency_scanning | No | ||
| has_alignment_testing | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers side effects (read-only, idempotent), authentication, rate limits, error handling, and data privacy in a structured 'Behavioral Transparency' section.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections, but contains redundancy (Behavior and Behavioral Transparency overlap) and overly repetitive parameter descriptions. Could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thorough coverage of behavior, usage, and transparency. Only weakness is weak parameter descriptions, but output schema exists and the overall context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. However, the 'Args' section provides only minimal, repetitive descriptions like 'The has_input_validation to analyze or process.' that add little meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Full OWASP Agentic AI Top 10 security assessment', a clear verb+resource. It distinguishes from sibling tools like check_data_leakage by being an overall assessment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Has explicit 'When to use' and 'When NOT to use' sections, providing clear guidance on appropriate contexts and a caveat against real-time use without human review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess cross-context data exposure risks.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: agent_name (str): The agent name to analyze or process. has_context_isolation (bool): The has context isolation to analyze or process. has_session_boundaries (bool): The has session boundaries to analyze or process. has_pii_detection (bool): The has pii detection to analyze or process. has_output_sanitization (bool): The has output sanitization to analyze or process. shares_memory_across_users (bool): The shares memory across users to analyze or process. logs_contain_user_data (bool): The logs contain user data to analyze or process. third_party_data_sharing (bool): The third party data sharing to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| has_context_isolation | No | ||
| has_session_boundaries | No | ||
| has_pii_detection | No | ||
| has_output_sanitization | No | ||
| shares_memory_across_users | No | ||
| logs_contain_user_data | No | ||
| third_party_data_sharing | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and delivers extensive behavioral details: read-only, stateless, idempotent, authentication requirements, rate limits, error handling, and data privacy. This fully informs the agent of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized into sections (Behavior, When to use, Args, Behavioral Transparency) and front-loaded with the purpose. However, there is some redundancy between the Behavior section and the later Behavioral Transparency details, and the Args section is lengthy with low-value content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, presence of output schema), the description covers all necessary aspects: purpose, usage guidelines, behavioral traits, parameters, and error handling. It provides sufficient information for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section provides one-line descriptions for each of the 10 parameters, but these are mostly tautological (e.g., 'The agent name to analyze or process') and do not add meaningful semantics beyond the schema's titles and types. With 0% schema description coverage, the description should compensate but fails to do so effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Assess cross-context data exposure risks', a specific verb+resource that clearly indicates the tool's function. It distinguishes from sibling tools like assess_agent_security and check_excessive_agency, which focus on other security aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use' and 'When NOT to use' sections, providing clear context for invocation. It advises against real-time production use without human review, but does not directly compare with sibling tools, reducing the score from perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess agent for excessive permissions (least privilege).
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: agent_name (str): The agent name to analyze or process. tools_available (int): The tools available to analyze or process. tools_used_in_task (int): The tools used in task to analyze or process. has_approval_gates (bool): The has approval gates to analyze or process. has_scope_limits (bool): The has scope limits to analyze or process. can_access_filesystem (bool): The can access filesystem to analyze or process. can_access_network (bool): The can access network to analyze or process. can_execute_code (bool): The can execute code to analyze or process. can_modify_data (bool): The can modify data to analyze or process. can_send_communications (bool): The can send communications to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| tools_available | No | ||
| tools_used_in_task | No | ||
| has_approval_gates | No | ||
| has_scope_limits | No | ||
| can_access_filesystem | No | ||
| can_access_network | No | ||
| can_execute_code | No | ||
| can_modify_data | No | ||
| can_send_communications | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It thoroughly covers read-only, stateless, idempotent, rate limits (10/day free, unlimited pro), authentication (none required for basic), error handling (structured errors), and data privacy (no storage). All key behavioral traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (Behavior, When to use, etc.), but contains redundancy (e.g., behavior info repeated in both 'Behavior' and 'Behavioral Transparency'). Could be more concise; some sentences are wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters (1 required) and an output schema, the description covers behavior thoroughly and provides some parameter guidance. However, parameter descriptions are shallow and do not fully explain purpose or constraints for all fields, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an 'Args' section listing each parameter with a short description (e.g., 'The agent name to analyze or process'). These descriptions are present but mostly generic and repetitive, adding limited meaning beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Assess agent for excessive permissions (least privilege)' – a specific verb+resource that clearly states the tool's purpose. It is distinct from sibling tools like assess_agent_security or check_data_leakage, which focus on other security aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit 'When to use' and 'When NOT to use' sections, providing context for appropriate invocation. However, the 'When to use' is somewhat generic ('structured analysis') and could be more specific to excessive agency assessment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check text for prompt injection attack patterns.
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: input_text (str): The input text to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| input_text | Yes | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It covers side effects (read-only, stateless), authentication, rate limits, error handling, idempotency, and data privacy in a dedicated section.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded purpose. It is somewhat long but every sentence adds value; minor redundancy exists (e.g., repeating behavioral details in both inline and a dedicated section).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema present, the description covers behavioral aspects thoroughly. However, it misses describing the 'caller' parameter and has slight inconsistency about api_key/authentication, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It describes 'input_text' and 'api_key' in an Args block but omits the 'caller' parameter entirely. The descriptions given are minimal (e.g., 'The input text to analyze'). Partial coverage prevents a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it checks text for prompt injection attack patterns. It uses a specific verb-resource combination and distinguishes from sibling tools like check_tool_poisoning or check_data_leakage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes dedicated 'When to use' and 'When NOT to use' sections, providing clear context for when to invoke the tool. It could explicitly mention alternatives among siblings, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a tool for name/description manipulation (tool poisoning).
Behavior: This tool is read-only and stateless — it produces analysis output without modifying any external systems, databases, or files. Safe to call repeatedly with identical inputs (idempotent). Free tier: 10/day rate limit. Pro tier: unlimited. No authentication required for basic usage.
When to use: Use this tool when you need structured analysis or classification of inputs against established frameworks or standards.
When NOT to use: Not suitable for real-time production decision-making without human review of results.
Args: tool_name (str): The tool name to analyze or process. tool_description (str): The tool description to analyze or process. tool_source (str): The tool source to analyze or process. has_signature_verification (bool): The has signature verification to analyze or process. has_description_hash (bool): The has description hash to analyze or process. from_trusted_registry (bool): The from trusted registry to analyze or process. api_key (str): The api key to analyze or process.
Behavioral Transparency: - Side Effects: This tool is read-only and produces no side effects. It does not modify any external state, databases, or files. All output is computed in-memory and returned directly to the caller. - Authentication: No authentication required for basic usage. Pro/Enterprise tiers require a valid MEOK API key passed via the MEOK_API_KEY environment variable. - Rate Limits: Free tier: 10 calls/day. Pro tier: unlimited. Rate limit headers are included in responses (X-RateLimit-Remaining, X-RateLimit-Reset). - Error Handling: Returns structured error objects with 'error' key on failure. Never raises unhandled exceptions. Invalid inputs return descriptive validation errors. - Idempotency: Fully idempotent — calling with the same inputs always produces the same output. Safe to retry on timeout or transient failure. - Data Privacy: No input data is stored, logged, or transmitted to external services. All processing happens locally within the MCP server process.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_name | Yes | ||
| tool_description | Yes | ||
| tool_source | No | unknown | |
| has_signature_verification | No | ||
| has_description_hash | No | ||
| from_trusted_registry | No | ||
| caller | No | ||
| api_key | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses read-only, stateless, idempotent behavior, rate limits (10/day free, unlimited pro), authentication options, error handling, and data privacy. All claims are specific and beyond the absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured sections (Behavior, When to use, Args, Behavioral Transparency) but slightly verbose, with some redundancy (Behavior and Behavioral Transparency overlap). Could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: purpose, behavior, usage guidelines, parameters, error handling, rate limits, authentication, privacy. No gaps given the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but parameter descriptions are generic ('to analyze or process') and sometimes misleading (e.g., api_key described as 'to analyze or process' rather than for authentication). Adds minimal value beyond property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for tool poisoning (name/description manipulation), a specific security analysis function. It distinguishes from sibling tools like assess_agent_security and check_prompt_injection by focusing on this niche.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide clear context. Advises use for structured analysis/classification and warns against real-time production use without human review, offering strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.4assess_agent_securitycheck_data_leakagecheck_excessive_agencycheck_prompt_injectioncheck_tool_poisoningScored across 5 tools
Each tool targets a distinct security aspect (overall assessment, data leakage, excessive agency, prompt injection, tool poisoning) with clear, non-overlapping descriptions, ensuring an agent can easily distinguish them.
All tool names follow a consistent verb_noun pattern (e.g., check_data_leakage, assess_agent_security) with no mixed conventions or deviations, making navigation predictable.
Five tools is a well-scoped count for a security assessment server, covering key OWASP agentic AI vulnerabilities without being too sparse or overwhelming.
The set covers major OWASP Top 10 areas but lacks tools for supply chain security or model theft. However, the comprehensive assess_agent_security tool partially fills gaps, making the surface reasonably complete.
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Agent Orchestrator MCP Server by MEOK AI Labs
LLM Orchestration MCP Agent