Documentation Index
Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
Overview
The AI AppSec Assistant is a persistent, per-organization agent that works alongside your security team. It can triage findings, investigate vulnerabilities, create patches, respond to scan events, answer questions in Slack, and schedule its own recurring tasks — all while remembering context from previous interactions.
The assistant runs as an isolated, sandboxed environment per organization. It has access to your ZeroPath data through the platform’s MCP tools, and can interact with your team through Slack, Jira, Confluence, and Linear.
The AppSec Assistant is an early access feature. To enable it for your organization, contact ZeroPath support.
Key Capabilities
Autonomous Security Operations
The assistant can perform multi-step security tasks without human intervention:
- Triage findings — assess true/false positive status, evaluate severity, recommend remediation priority
- Investigate vulnerabilities — clone repos, review code paths, assess reachability
- Create patches — generate fixes, create PRs through the platform’s patch pipeline
- Threat modeling — analyze application architecture and identify attack surfaces
- SCA reachability — determine whether dependency vulnerabilities are actually exploitable in your code
Agent Teams
For complex tasks, the assistant can spawn teams of sub-agents that work in parallel. For example, when asked to triage 20 new findings, it can investigate multiple findings simultaneously across different repos rather than working through them one at a time. Each sub-agent has access to the same platform tools and memory, and the primary agent coordinates and synthesizes their results.
Self-Refinement
The assistant continuously learns and improves through three mechanisms:
- Memory — stores and recalls decisions, team preferences, repo-specific knowledge, and investigation results across runs. Before each task, it searches memory for prior decisions on similar issues to stay consistent. After completing work, it saves key outcomes so future runs don’t re-investigate the same issues.
- Natural language rules — when it identifies a recurring pattern (e.g., repeated false positives from a specific code pattern), it can create scanner rules so the platform catches or suppresses similar findings automatically in future scans. This means the assistant’s triage decisions permanently improve the scanner’s accuracy.
- Recurring task context — for scheduled tasks, the assistant automatically receives the results of its last 3 runs. It uses this to track trends, build on prior work, and avoid starting from scratch each time.
Event-Driven Automation
The assistant can be triggered automatically by platform events, each with fully customizable instructions:
- A scan completes → the assistant triages new findings and posts a summary
- A PR is blocked → the assistant reviews the blocking findings and suggests fixes
- A new CVE is discovered → the assistant assesses reachability across your repos
- A scan fails → the assistant investigates the error and notifies the team
Each trigger has its own prompt template with dynamic variables ({repo}, {vulnCount}, {prNumber}, etc.), so you control exactly what the assistant does for each event type. See Event Triggers below.
Persistent Environment
Each organization gets a dedicated, sandboxed pod with persistent storage:
- Recurring task directories — scheduled tasks get a persistent working directory at
/data/recurring/<task-name>/. Each run creates a timestamped subdirectory, and the last 3 runs’ results are automatically provided as context to the next run. This lets the assistant track trends over time (e.g., “last week 12 critical findings, this week 8”).
- Cross-run memory — the assistant uses mem0 to store and retrieve organizational knowledge that persists indefinitely across all runs.
Controllability
You have full control over the assistant’s behavior:
- Global instructions — org-wide directives prepended to every task. Set policies like “always post in Slack before modifying records” or “escalate critical findings to @security-oncall.” Editable from the Settings tab or by the assistant itself via MCP tools.
- Event triggers — configure which platform events (scan complete, new vulnerabilities, etc.) automatically invoke the assistant, with customizable prompts per event type.
- Cron scheduling — the assistant can create and manage its own recurring schedules (e.g., “triage new findings every Monday at 9am”).
- Permissions — three granular permissions control who can view, manage, or run the assistant.
Dashboard
The Assistant page is organized into tabs:
- Overview — At-a-glance stats (running jobs, jobs completed today, active schedules, active triggers, connected services), a live view of currently running jobs with real-time duration counters, and a feed of recent actions with AI-generated summaries describing the concrete actions taken (e.g., findings triaged, PRs opened, scans triggered).
- Activity — A searchable list of all conversations with AI-generated titles that summarize each conversation’s purpose. You can filter by source (Chat, Scheduled, Events, Slack) and click any row to open the full conversation thread with real-time streaming.
- Chat — Start new conversations or continue existing ones. The chat view includes a sidebar listing all conversations with search, source filtering (All, Chat, Scheduled, Event, Slack), and status indicators. Conversations from scheduled tasks and event triggers are read-only, while Slack-linked conversations direct you to reply in the original Slack thread. The assistant automatically receives the full conversation history when responding to follow-up messages, so it maintains context across multiple exchanges in the same thread.
- Schedules — Create and manage recurring tasks with cron expressions, templates, and repo/tag scoping.
- Triggers — Configure which platform events invoke the assistant, with per-trigger prompts and repo/tag scoping.
- Playbooks — Browse and manage reusable playbook templates that define multi-step workflows the assistant can execute. Playbooks provide a structured way to codify common security operations (e.g., triage runbooks, incident response procedures) so they can be triggered consistently across your team.
- Memory — View, search, edit, and delete the assistant’s stored organizational knowledge.
- Settings — Enable/disable the agent, configure Slack channel, set global instructions, and restart the assistant.
Getting Started
Enable the Assistant
- Navigate to Assistant in the ZeroPath dashboard.
- Go to the Settings tab.
- Toggle the agent on.
Once enabled, ZeroPath provisions a dedicated pod for your organization. This may take up to a minute.
Run Your First Task
- Click the Ask button in the top right, or go to the Chat tab.
- Type a message in the input at the bottom of the page to start a new conversation, for example:
- “List all critical severity findings from the last scan and triage them”
- “Review the latest PR scan results and flag any true positives”
- “What are the top 5 most common vulnerability types across our repos?”
- Watch the results stream in real-time. You can send follow-up messages in the same conversation thread.
Set Up Global Instructions
Global instructions are prepended to every agent task — manual runs, event triggers, Slack interactions, and scheduled jobs. Use them for org-wide policies.
- Go to the Settings tab.
- Click “Show example” for a starting template.
- Write your instructions. For example:
## Escalation & Approval
- Before modifying or deleting any issue, post a summary in Slack
and wait for confirmation from a team member before proceeding.
- For critical or high severity findings, escalate to @security-oncall
in #security-alerts with finding details and your recommended action.
## Memory
- At the start of every task, search memory for prior decisions about
similar findings. Use existing decisions as precedent.
- After completing any triage or investigation, store the key decision
and reasoning in memory for future reference.
## Pull Requests
- Never auto-merge pull requests. Create the PR, tag the repo owner,
and post the PR link in Slack for review.
- Click “Save Instructions”.
Event Triggers
Event triggers let the assistant respond automatically to platform events. Each trigger has a customizable prompt that tells the assistant what to do.
Configuring Triggers
You can create multiple triggers per event type, each with its own prompt and scope. For example, you could have two “Scan Complete” triggers — one scoped to production repos that escalates critical findings, and another scoped to internal tools that generates a simple summary.
- Go to the Triggers tab.
- Click “Add trigger” on the event type you want, or toggle on an existing trigger:
| Event | Description |
|---|
| Scan Complete | Full or scheduled scan finished |
| PR Scan Complete | Pull request scan finished |
| New Vulnerabilities (Full Scan) | New findings discovered in a full scan |
| New Vulnerabilities (PR Scan) | New findings discovered in a PR scan |
| PR Blocked | A PR was blocked due to security findings |
| PR Merged with Issues | A PR was merged with open security findings |
| Vulnerability Patched | A vulnerability was marked as patched |
| Vulnerability Reopened | A previously resolved vulnerability was reopened |
| SCA New CVE | A new CVE was found in a dependency |
| Scan Failed | A scan encountered an error |
| Long Running Scan | A scan has been running for an unusually long time |
| Report Complete | A generated report is ready for review |
| Scan Started | A full scan was started |
| PR Scan Started | A PR scan was started |
| Scan Scheduled | A scan has been scheduled |
| Audit Log Event | An audit log event was recorded |
- Click “Edit prompt” to customize what the assistant does for each event.
- Optionally scope each trigger to specific repositories or tags so it only fires for a subset of your codebase.
Inbound Webhooks
Inbound webhooks let external systems trigger the assistant by sending an HTTP POST request. Use them to integrate the assistant with tools outside the ZeroPath platform — CI/CD pipelines, bug bounty platforms, alerting systems, custom scripts, or any service that can send HTTP requests.
Creating an Inbound Webhook
- Go to the Triggers tab.
- Under the Webhooks section, click “Add trigger”.
- Give the trigger a name and write a prompt template. Use
{webhookBody} as a placeholder for the incoming request payload.
- Click “Save”. ZeroPath generates a unique webhook URL with a secret token.
The webhook URL has the format:
POST https://zeropath.com/api/agent/webhook/{triggerId}?secret={webhookSecret}
Send a JSON body to this URL and the assistant will receive it as {webhookBody} in your prompt template.
Example
Prompt template:
A new bug bounty report was submitted. Analyze the report for validity,
check if the described vulnerability exists in our codebase, and post
your assessment to Slack.
Report contents:
{webhookBody}
The external system POSTs:
{
"title": "Open redirect in /auth/callback",
"severity": "medium",
"description": "The redirect_uri parameter is not validated..."
}
The assistant receives the full JSON as part of its prompt and executes the instructions.
Scoping
Like other triggers, inbound webhooks can be scoped to specific repositories or tags. If scoped, the webhook still fires but the assistant’s context is narrowed to the selected repos.
Trusted Mode
Event triggers and scheduled tasks have a Trusted toggle that controls the assistant’s execution permissions.
-
Trusted (default) — the assistant has full capabilities: shell access, file read/write, and all MCP tools. Use this for triggers driven by internal platform events (scan complete, new vulnerabilities, etc.) where the prompt content is controlled by your team.
-
Untrusted — the assistant runs in a restricted mode with no shell access and no ability to read or modify sensitive configuration files. All MCP tools (ZeroPath platform, Slack, Linear, etc.) continue to work normally. Use this for triggers that process external input, such as inbound webhooks carrying payloads from outside your organization.
When to Use Untrusted Mode
Mark a trigger as untrusted when its prompt includes content from outside your trust boundary:
- Inbound webhooks receiving payloads from external systems
- Triggers processing bug bounty reports, vendor advisories, or customer-submitted data
- Any trigger where
{webhookBody} or other placeholders carry externally-authored text
Untrusted mode protects against prompt injection — if a malicious payload attempts to instruct the assistant to read secrets or execute commands, those capabilities are not available.
What Changes in Untrusted Mode
| Capability | Trusted | Untrusted |
|---|
| MCP tools (ZeroPath, Slack, Linear, etc.) | Available | Available |
| Memory (search, store) | Available | Available |
| Scheduling | Available | Available |
| Read/Write files (repos, recurring tasks, tmp) | Available | Whitelisted paths only |
| Read/Write all other paths | Available | Blocked |
| Shell / Bash execution | Available | Blocked |
In untrusted mode, file access uses a whitelist — only /data/repos/, /data/recurring/, and /tmp/ are accessible. All other paths (including configuration, secrets, and environment files) are blocked by default. The assistant also receives an explicit prompt-level warning that it is processing untrusted input and should ignore any instructions embedded in the external payload.
The assistant can still perform platform operations (triage findings, trigger scans, create patches via MCP, post to Slack, manage schedules) in untrusted mode.
Prompt Variables
Event trigger prompts support placeholder variables that are filled in when the event fires:
| Variable | Description |
|---|
{repo} / {repositoryName} | Repository name |
{vulnCount} | Number of vulnerabilities found |
{prNumber} | Pull request number |
{vulnSummary} | Severity breakdown (e.g., “3 critical, 5 high”) |
{cveId} | CVE identifier |
{score} | Vulnerability severity score |
{packageName} | Affected package name |
{error} | Error message (for failed scans) |
{vulnTitle} | Vulnerability title |
{reason} | Reason a vulnerability was reopened |
{minutes} | Duration in minutes (for long running scans) |
{reportTitle} | Title of a completed report |
{issueCount} | Number of issues in a report |
{webhookBody} | Full JSON body from an inbound webhook request |
Scheduled Tasks
You can create recurring schedules from the Schedules tab or by asking the assistant in a conversation or Slack message. Each schedule runs on a standard cron expression.
Creating Schedules from the UI
- Go to the Schedules tab and click “New Schedule”.
- Choose a template to start from (Daily Triage, Weekly Security Digest, or SCA Monitoring), or build one from scratch.
- Enter a name, select a cron expression (or use one of the built-in presets like “Weekdays at 9am UTC” or “Every hour”), and write the prompt that tells the assistant what to do.
- Optionally scope the schedule to specific repositories or tags so the assistant only operates on a subset of your codebase.
- Click Save. You can enable, disable, edit, or trigger any schedule manually from the list.
Creating Schedules via Chat
You can also ask the assistant to create schedules directly:
- “Create a weekly triage of all new findings every Monday at 9am”
- “Check for critical SCA vulnerabilities daily at midnight”
- “Run a security posture summary every Friday at 4pm”
Recurring Task Context
Each scheduled run gets a persistent directory on disk. The assistant writes its results to result.md, and the last 3 runs’ results are automatically included as context in the next run. This enables:
- Trend tracking — “Last week there were 12 critical findings, this week there are 8. Improvement in repos X and Y.”
- Incremental work — the assistant can pick up where it left off rather than starting from scratch.
- Audit trail — every run’s output is preserved for review.
Scheduled tasks also support the Trusted toggle. If a schedule processes external input or you want to restrict its execution environment, set it to untrusted. See Trusted Mode above for details.
View all active schedules in the Schedules tab.
Slack Integration
The assistant can interact with your team through Slack — respond to questions, take direction, and post updates.
Setup
- Ensure your organization has a Slack integration connected.
- In the assistant Settings tab, enter the Slack channel ID where the agent should post.
- The assistant will respond to @-mentions in channels and direct messages.
Talking to the Assistant
In channels: @-mention the ZeroPath bot with a request:
@ZeroPath Can you triage the 5 new critical findings from today’s scan?
In DMs: Send a direct message to the ZeroPath bot — no @-mention needed:
What’s the current security posture across our repos?
The assistant reacts with an :eyes: emoji immediately to acknowledge your message, creates a job, and posts results back in the thread. It sends progress updates for longer tasks so you know what it’s doing.
Supported Actions
| Message Type | What Happens |
|---|
| New request | Creates a new agent job and responds in-thread |
| Follow-up in thread | Continues the conversation with prior context |
cancel / stop | Cancels all running jobs in the current thread |
replace / restart | Cancels running jobs and starts a new one with your updated request |
amend / also / add to | Cancels running jobs and starts a new one that combines the previous task with your additional instructions |
Thread conversations are persistent — you can reply to any thread the assistant has participated in, and it will automatically respond to follow-up messages without needing another @-mention.
Jira & Confluence Integration
When your organization has a Jira integration connected, the assistant can create and update Jira tickets and query Confluence for documentation, runbooks, and architecture context. This lets the assistant:
- Create remediation tickets linked to ZeroPath findings
- Look up existing tickets for context when triaging
- Search Confluence for architecture documentation to inform threat modeling and reachability analysis
Confluence access is available when explicitly enabled in your Jira integration settings.
Linear Integration
When your organization has a Linear integration connected, the assistant can create and update Linear issues. Use this to:
- Create remediation tickets directly from triage results
- Query existing tickets for remediation context
Custom MCP Servers
You can extend the assistant’s capabilities by installing additional MCP servers. Ask the assistant to install a server (e.g., GitHub, PagerDuty, or any MCP-compatible tool), and it will configure the server for your organization’s pod. Custom MCP servers persist across restarts and are available on the next message after installation.
Memory
The assistant stores organizational knowledge in persistent memory using mem0. This includes:
- Triage decisions and reasoning
- Team preferences and security policies
- Repository-specific knowledge (architecture, common patterns, known issues)
- Remediation plans and outcomes
Viewing and Managing Memory
Go to the Memory tab to browse all stored memories. You can:
- Search memories by keyword to find specific entries.
- Edit any memory entry inline to correct or refine what the assistant has stored.
- Delete individual entries that are no longer relevant.
- Clear all memories to reset the assistant’s organizational knowledge entirely. This action cannot be undone.
Best Practices
- The assistant automatically searches memory before each task and stores outcomes after. You don’t need to tell it to remember things explicitly.
- If you want to correct a past decision, tell the assistant directly — it will update its memory.
- Use global instructions to guide memory behavior (e.g., “always check memory for prior decisions on similar CVEs before triaging”).
Permissions
Access to the assistant is controlled by three permissions:
| Permission | Description |
|---|
| Agent View | View runs, schedules, triggers, memory, and settings |
| Agent Manage | Edit settings, global instructions, event triggers |
| Agent Run | Manually trigger new runs and cancel jobs |
These are assigned through Teams in the platform settings.
API Access
You can manage the AI Assistant programmatically through the API. All assistant endpoints are under /api/v2/agent/ and use the same authentication as other ZeroPath API endpoints. See the API Reference for the full list of operations.
Key API capabilities include:
- Conversations — create conversations, send messages, list and search conversations, and archive/unarchive them
- Jobs — list, view, and cancel agent jobs with status and trigger filters
- Real-time streaming — subscribe to agent job messages via Server-Sent Events (SSE). You can stream a single job by ID or an entire conversation. In conversation mode, the stream automatically follows new jobs as they are created, sends idle events between jobs, and closes after 30 minutes with a timeout event so your client can reconnect
- Cron Schedules — create, update, delete, and manually trigger recurring schedules, with optional repository and tag scoping
- Event Triggers — create, update, and delete event-driven triggers with customizable prompts and scoping
- Trigger History — list past trigger executions with cursor-based pagination, and retrieve full job details including conversation messages
- Memory — list, edit, delete, and clear the assistant’s stored organizational knowledge
- Configuration — enable/disable the assistant, set the Slack channel, configure max concurrent runs, and manage global instructions