PolicyGuard
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tasks | {
"list": {},
"cancel": {},
"requests": {
"tools": {
"call": {}
},
"prompts": {
"get": {}
},
"resources": {
"read": {}
}
}
} |
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_compliance_statusA | Get compliance status and security health metrics. Generates a compliance report showing policy violations, security incidents, and overall governance health for the specified time period. Args: time_range: Time range - "1h", "24h", "7d", "30d" (default: "24h") include_incidents: Include active incidents in report (default: true) include_policy_summary: Include policy overview (default: true) Returns: JSON string with compliance report: - status: Overall status ("healthy", "warning", "critical") - metrics: Key security metrics - incidents: Active security incidents (if requested) - policies: Policy summary (if requested) - recommendations: Suggested actions to improve security Example: # Get daily compliance status get_compliance_status(time_range="24h") |
| create_policyA | Create or update a security policy for agent governance. Policies define rules that control what agents can do. Each policy contains conditions and actions (allow/deny/require_approval). Args: policy_id: Unique identifier for the policy (e.g., "prod-db-access") name: Human-readable name (e.g., "Production Database Access Control") description: Description of what this policy controls rules: JSON array of rule objects. Each rule has: - condition: Object with matching criteria - tool_pattern: Glob pattern for tool names (e.g., "database_*") - action_type: Type of action (e.g., "tool_call") - trust_level_at_least: Minimum trust level required - trust_level_below: Trigger if trust below this level - action: "allow", "deny", or "require_approval" - message: Message to show when rule matches priority: Higher priority policies are evaluated first (default: 100) enabled: Whether the policy is active (default: true) Returns: JSON string with creation result: - success: Whether creation succeeded - policy_id: The policy's ID - message: Status message Example: create_policy( policy_id="prevent-deletions", name="Prevent Dangerous Deletions", description="Block delete operations for non-admin agents", rules='[{"condition": {"tool_pattern": "delete_*", "trust_level_below": "admin"}, "action": "deny", "message": "Delete operations require admin access"}]' ) |
| get_audit_logA | Retrieve audit log entries for compliance and investigation. The audit log records all action validations, policy violations, and administrative actions performed through Guardian Agent. Args: agent_id: Filter by specific agent ID (optional) action_type: Filter by action type like "tool_call", "resource_access" (optional) time_range: Time range to query - "1h", "24h", "7d", "30d" (default: "24h") status: Filter by status - "allowed", "denied", or "" for all (optional) limit: Maximum number of entries to return (default: 100) Returns: JSON string with: - entries: Array of audit log entries - count: Number of entries returned - total: Total entries matching filter (before limit) - time_range: The time range used - filters_applied: Summary of filters used Example: # Get all denied actions in the last hour get_audit_log(time_range="1h", status="denied") |
| report_incidentA | Report a security incident for investigation and tracking. Use this tool to log security incidents such as policy violations, suspicious agent behavior, or potential security threats. Args: incident_type: Type of incident: - "policy_violation": Agent violated a security policy - "suspicious_activity": Unusual or potentially malicious behavior - "unauthorized_access": Attempt to access restricted resources - "rate_limit_exceeded": Agent exceeded rate limits - "data_exfiltration": Potential data leak detected - "configuration_error": Security misconfiguration detected - "other": Other security concern severity: Incident severity: - "low": Minor issue, no immediate action needed - "medium": Notable issue, should be reviewed - "high": Serious issue, needs prompt attention - "critical": Emergency, immediate action required description: Detailed description of the incident agent_id: ID of the agent involved (if applicable) evidence: JSON object with supporting evidence/data recommended_action: Suggested remediation steps Returns: JSON string with: - incident_id: Unique incident identifier - success: Whether the incident was logged - message: Status message - agent_suspended: Whether the agent was auto-suspended Example: report_incident( incident_type="suspicious_activity", severity="high", description="Agent attempted to access 50 databases in 1 minute", agent_id="rogue-agent-01", evidence='{"databases_accessed": 50, "time_window": "60s"}', recommended_action="Review agent permissions and suspend if needed" ) |
| register_agentA | Register a new agent with Guardian for security policy evaluation. Registered agents get proper trust levels and can have custom tool permissions. Unregistered agents are treated as 'low' trust. Args: agent_id: Unique identifier for the agent (e.g., "prod-assistant-01") name: Human-readable name (e.g., "Production Assistant") description: Description of the agent's purpose trust_level: Trust level - "low", "medium", "high", or "admin" allowed_tools: JSON array of allowed tool patterns (e.g., '["read_*", "query_*"]') denied_tools: JSON array of denied tool patterns (e.g., '["delete_*", "drop_*"]') metadata: JSON object with additional agent metadata Returns: JSON string with registration result: - success: Whether registration succeeded - agent_id: The agent's ID - message: Status message - warnings: Any warnings about the registration Example: register_agent( agent_id="data-analyst-01", name="Data Analyst Bot", description="Runs analytical queries on warehouse", trust_level="medium", allowed_tools='["query_*", "read_*"]', denied_tools='["delete_*", "drop_*", "truncate_*"]' ) |
| validate_actionA | Validate whether an agent can perform a specific action. This is the PRIMARY security gate. Agents should call this BEFORE performing any sensitive action to ensure compliance with security policies. Args: action_type: Type of action (e.g., "tool_call", "resource_access", "data_read", "data_write") target: Target of the action (e.g., tool name, resource URI, database name) agent_id: Unique identifier of the requesting agent parameters: JSON string of action-specific parameters (optional) context: Additional context about why this action is needed (optional) Returns: JSON string with validation result: - action_id: Unique ID for this validation (for audit correlation) - allowed: Whether the action is permitted - require_approval: If true, action needs human approval first - reason: Explanation of the decision - warnings: Any non-blocking warnings Example: validate_action( action_type="tool_call", target="database_delete", agent_id="prod-agent-01", parameters='{"table": "users"}', context="Cleanup stale records" ) |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a distinct and clearly defined purpose: create_policy defines policies, get_audit_log retrieves logs, get_compliance_status provides reports, register_agent manages agents, report_incident logs incidents, and validate_action checks permissions. There is no overlap or ambiguity in their functions.
All tool names follow a consistent verb_noun pattern (e.g., create_policy, get_audit_log, register_agent). The verbs are appropriate and descriptive, and there are no deviations or mixed conventions, making the set highly predictable.
With 6 tools, the server is well-scoped for agent governance and security policy management. Each tool serves a clear role in the lifecycle (e.g., policy creation, agent registration, action validation, incident reporting, auditing, and compliance), with no redundant or missing tools.
The tool set provides complete coverage for the security policy domain: create_policy for policy management, validate_action for enforcement, get_audit_log and get_compliance_status for monitoring, register_agent for agent setup, and report_incident for incident handling. There are no obvious gaps, enabling full agent governance workflows.