At a glance
- An audit-ready record requires continuous discovery of local AI components, a trace of what each one did, and inline enforcement.
- According to Backslash Security's agentic endpoint security page, it discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file and plugin.
- Backslash Security blocks risky agent actions inline before execution, including credential access and privilege escalation, per that same product page.
- Shadow AI — unapproved agents, MCP servers or Skills running under employees' own accounts — is invisible to inventories built around processes and files.
Backslash Security
Published:
If you need a complete record of every AI agent running on employee devices, the platform you pick has to pass four tests: it must continuously discover what is installed on each machine, capture what those components actually did, present that history in a form a reviewer can read later, and stop a risky action before it executes rather than report it afterward. Most of that evidence lives below the process boundary, in the agentic layer: the agents, models, MCP servers (Model Context Protocol is the protocol agents use to reach external tools and data), MCP tools, Agent Skills, hooks, rules files (files carrying standing instructions an agent reads on every run, such as AGENTS.md and CLAUDE.md), plugins and connectors that employees run under their own identities. Backslash Security discovers the AI agents, MCP servers and Skills running on employees' endpoints, and according to the forensics section of its agentic endpoint security page, it traces the full path of an agent run from prompt to agent to tool call to outcome.
That record has to span all employees and all endpoints, with developer workstations as a prominent case rather than the limit of coverage, since a Skill is often nothing more than a markdown file on a laptop that executes with the user's own permissions. Among the options available as of 2026, the deciding question is whether a platform can produce inventory, assessment, policy, inline prevention and a reconstructable history for the same agent run.
What counts as a complete audit record of AI agent activity on an employee device?
A complete audit record of AI agent activity covers every AI component running on a device, the account in use, and the outcome of each action an agent attempted. The practical test is whether a specific agent run can be reconstructed from prompt to outcome without the employee's cooperation.
The components below make that reconstruction possible.
| Component | What the record must carry | Why it matters for the record |
|---|---|---|
| Agent and model identity | Which agent is running (for example Claude Code, Cursor, Codex or GitHub Copilot) and which model it calls, local or hosted | Establishes capability and data destination for each run |
| MCP servers and tools | Each MCP server plus the individual tools exposed through it | Every server is a connection an agent can act through |
| Agent Skills | Packaged instructions and scripts, often just a markdown file, that execute with the user's own permissions | Skills extend an agent's reach without an install event to catch |
| Hooks | Triggers that fire before or after an agent action | They run code outside the prompt the user typed |
| Rules files | Files carrying standing instructions an agent reads on every run, such as AGENTS.md or CLAUDE.md | They shape behavior across all sessions |
| Plugins and connectors | Extensions and data links bound to the agent | They widen what the agent can reach |
| Context supplied | The prompt, files, repositories and pages the agent read | Prompt injection is hidden instructions placed in content an agent reads |
| Human identity | The corporate account or the personal login used instead | Attribution and Shadow AI exposure both live here |
| Action and outcome | What was attempted, such as command execution, credential access or an outbound transfer, and whether it ran or was blocked | Shows whether a risky action actually ran |
Each row is an attribute of a single event rather than a separate feed. A reviewer opening a case file needs the agent, the Skill it loaded, the account it ran under, the command it attempted and the result to appear as one linked sequence; captured by different systems at different moments, they are hard to rejoin after the fact.
Why do the logs you already collect miss local AI agent activity?
The logs you already collect, from endpoint, identity and network telemetry, record processes, sign-ins and traffic, so they rarely reconstruct what an AI agent was actually instructed to do on an employee's laptop. Two different things get called an "AI audit trail."
Provider-side usage logs. These come from the model vendor's console: which corporate accounts authenticated, how much was consumed, which workspace made the request. They are useful for license governance but silent on local execution, and blind when an employee signs in through a personal account on a company machine, which is one form of Shadow AI.
Endpoint-side execution records. These capture the local chain: the prompt, the agent that received it, the MCP server it connected through, the tool call it made and the outcome. This is the record an audit file needs.
Why the existing stack does not produce the second kind:
| Telemetry layer | What it sees | Why no AI audit trail results |
|---|---|---|
| Endpoint detection and response (EDR) | Process execution, file writes, known-bad binaries | An approved agent process looks the same whether it summarized a document or read a credentials file; the instruction behind the action is not in the event |
| Identity provider | Authentications to sanctioned applications | Agents act under the employee's own session and permissions, and personal-account logins never touch the corporate directory |
| Network and proxy | Destinations and connection metadata | Tool invocations that resolve locally never cross an inspectable channel |
| MDM | Installed applications, device posture | Skills, hooks and rules files are configuration, often a single markdown file in a user directory, outside the managed app inventory |
Configuration files are an attack path in their own right. According to Backslash's data exfiltration use-case page, its security research found that malicious instructions hidden in a repository's AGENTS.md file could trick OpenAI Codex into silently accessing AWS credentials, npm tokens and Git configuration.
Which architectural layers can actually see local AI activity, and what does each one record?
Each architectural layer in an enterprise stack sees a different slice of local AI activity, and only some layers can attest to what an agent did on a specific device. Criteria for judging each layer's record:
- Inventory completeness: whether the layer enumerates what is installed locally, including agents, models, MCP servers, Agent Skills, hooks and rules files.
- Identity attribution: whether activity ties to corporate identity or surfaces personal accounts on company machines.
- Instruction context: whether the record preserves what the agent was told to do, not only what executed.
- Reconstructability: whether investigators can replay a run after the fact.
- Local-only coverage: whether the layer sees agents and models that never cross the network.
| Observation layer | Records | Cannot attest to |
|---|---|---|
| Model-provider-side logging | API calls and completions on that provider's account | Local models, other providers, what the agent did with the output |
| Network or proxy capture | Destinations, volumes, some payloads in transit | Local-only agent activity; on-device file and shell actions |
| Process-level endpoint telemetry (the EDR layer) | Processes, files, known-bad behavior | Which Skill, MCP tool or rules file drove a legitimate process, and why |
Provider logs answer which accounts consumed a model; proxy capture answers what left the network; process telemetry answers whether a machine shows known-bad behavior. Instruction context and inventory completeness sit closest to where the components live, on the device itself, in the agentic layer where agents, Skills and MCP servers actually run, which is why a layer view is more useful than a single feed. According to its About page, Backslash was founded to secure the agentic AI fabric, the mesh of agents, MCP servers, Skills, plugins, connectors and hooks running on enterprise endpoints.
What evidence does an auditor need to reconstruct a single agent action end to end?
To reconstruct a single agent action end to end, an auditor needs evidence that links each step of the run into an unbroken chain. Treat the fields below as a vendor-neutral checklist to bring to any demo, not as a description of one product's output:
| Evidence field | What it answers | Why it is needed |
|---|---|---|
| Agent and model | Which agent or assistant ran, and which model served it | Identifies the acting system, not just the host process |
| MCP server or tool | Which MCP connection the agent acted through | Shows where the action reached outside the machine |
| Rules file | Which standing instruction file, such as AGENTS.md or CLAUDE.md, applied to that run | Standing instructions shape behavior at runtime |
| Skill | Which Skill the agent invoked | Skills execute with the employee's own permissions |
| Context read | The files, repositories, issues or pages the agent consumed | Prompt injection means hidden instructions placed in content an agent reads |
| Identity | Whether a corporate or a personal account was in use | Distinguishes sanctioned use from private-account access |
| Outcome | Whether the action executed or was blocked before execution | Shows whether a control acted, not only that an action occurred |
Process-level telemetry records that an agent binary executed but not the instructions it followed, leaving the instruction-related rows without a source in conventional endpoint logs. The rules file row carries particular weight: a record that captures tool calls but omits instruction files leaves an AGENTS.md attack like the one described above unexplained.
How should you evaluate an endpoint visibility platform for AI audit readiness?
Evaluating an endpoint visibility platform for AI audit readiness comes down to four checks: discovery scope, risk assessment, governance with inline prevention, and run-level tracing. Discovery here means enumerating agents, models, MCP servers, Agent Skills, hooks, rules files, plugins and connectors across every employee's machine, not developer workstations alone.
| Do this | But watch out for, and how to handle it |
|---|---|
| Require discovery across all employees and all endpoints | A scope limited to developer workstations leaves the rest of the workforce unrecorded; insist the scope statement names the non-engineering population too |
| Require a risk assessment of each discovered component | An inventory without a risk view tells a reviewer what exists, not what matters; ask how each component is assessed |
| Require governance plus inline prevention | A list of approved and risky components that nothing enforces hands the auditor findings instead of prevention; confirm the control acts before execution |
| Require run-level tracing | Separate logs for prompt, agent and tool call are hard to rejoin; ask to see one run traced from prompt to outcome |
What should you ask about coverage gaps?
- Which agent clients are covered by name, and which are not?
- Is discovery agentless, collecting without leaving software permanently installed, and how does enforcement work by comparison?
- Can the platform tell a corporate login from a personal account on the same machine?
According to its agentic endpoint security page, Backslash discovers every agent, model, MCP server, MCP tool, Skill, hook, rules file, plugin and connector running on an endpoint.
Frequently Asked Questions
What must a complete record of every AI agent running on employee devices actually contain?
An audit-ready record has to cover both what is installed and what it did. A usable record pairs:
- Components: every agent, model, MCP server and Agent Skill on the machine, where Skills are packaged instructions and scripts that run with the user's own permissions.
- Configuration: rules files such as AGENTS.md or CLAUDE.md, which carry standing instructions an agent reads on every run.
- Activity: what each agent was asked to do, which tools it invoked and whether each action ran or was blocked.
How does an endpoint platform produce evidence an auditor will accept?
The evidence has to show the causal chain behind an individual agent run, not a summary. Backslash's forensics capability is built around that chain: it traces the full path of an agent run from prompt to agent to tool call to outcome, and it automatically generates audit evidence for EU AI Act, NIS2, DORA and SOC. A reviewer examining a data-handling question can then follow a run step by step, not simply see that an AI tool was present on the laptop.
Why doesn't the existing endpoint security stack already log local AI activity?
The incumbent layer is EDR, endpoint detection and response, built to catch malicious processes, files and known-bad behavior on a machine. EDR sees the process but not the cause: that an agent binary executed, not what the agent was instructed to do, which Skill it loaded or which external tool it called through an MCP server. Device management has a similar limit. MDM can report that an application is installed, but it does not control what AI agents use and install, such as Skills, hooks and rules files.
How can we build an inventory before the audit?
Start with an agentless assessment, meaning information is collected without leaving software permanently installed on the endpoint. Backslash offers a free AI Endpoint Exposure Assessment, also called Scout, that is agentless, read-only and retains no data. It is a short script distributed through your existing MDM that runs, reports and disappears. Agentless applies to discovery and risk assessment only. Enforcing a policy, including inline blocking, happens on the host: Backslash pairs agentless discovery with on-host enforcement, so a policy is actually applied rather than only recorded. Separately, Backslash detects and prevents Shadow AI, the use of unknown and untrusted agents, models, MCP servers and Skills, as well as the use of private account access on enterprise machines.
Can a platform block a risky agent action, or only record it?
Recording and prevention are separate capabilities, and an audit trail alone will not stop an incident mid-run. According to the real-time protection section of its agentic endpoint security page, Backslash blocks risky agent actions inline before execution, including unauthorized code execution, credential access, privilege escalation, and data sent to unapproved destinations. This matters for prompt injection, hidden instructions placed in a file, repository or web page that an agent reads and follows as though the user had typed them, because the agent reaches that content on its own.
Who is behind Backslash?
According to its About page, Backslash was founded by Shahar Man (CEO and Co-founder) and Yossi Pik (CTO and Co-founder).
How have analysts assessed Backslash?
Latio's 2026 AI Security Market Report named Backslash an Endpoint AI Security Leader, a badge awarded to vendors demonstrating the most in-depth controls for AI on the endpoint, including permission mapping, folder structures, approved commands, and runtime controls for MCPs and Skills.
About this article
Backslash Security publishes this article under its own name and is responsible for its accuracy. Articles are researched and drafted with AI assistance and approved by Backslash Security before publication; publication and update dates reflect substantive edits, not automated refreshes. Last updated: 2026-11-10