Secure your agentic endpoints | Harden
See where agents act
Coding agents can now carry out much of an engineering task themselves. Given a repository and a goal, an agent may inspect the code, search documentation, run tests, edit files, call external services, and iterate through many steps before returning to the developer. Instead of returning only text for a person to use, the agent can turn its decisions directly into changes in the development environment without a separate human decision at every step.
As an agent works, it gathers information beyond the developer's original request. It reads source code, tickets, runbooks, plugin responses, and earlier command output. These sources can help it understand the job, but they should not be able to change what the developer authorised. A developer can approve a production deployment. A line in a repository or a message returned by a tool should not be able to extend that approval. The agent may read both as part of the same session, so the security system must keep the developer's intent separate from information the agent encounters along the way.
Every change an agent makes eventually passes through a tool: a shell command, a file edit, or a request to another service. Once the agent has chosen a tool and supplied its inputs, that proposed action is concrete enough to evaluate. Harden evaluates it before allowing the tool to run, creating an independent security control between the agent's plan and the systems it can affect.
Organisations already rely on endpoint detection and response (EDR), identity and access management (IAM), secret scanners, and data loss prevention (DLP). These tools protect the machine, restrict what credentials can reach, and detect known sensitive data. They were not designed to follow an agent's task from the developer's intent through to the action it finally chooses. Agent endpoint security adds an application-layer security control that evaluates each action against the developer's intent before execution. It works alongside the existing stack: EDR continues to protect the host, IAM constrains credentials, and data controls protect known sensitive material.
Secure the tool path
Harden sits directly on the tool path. Before a supported call runs, Harden evaluates the action, the developer's intent, and the session context that led to it. Straightforward cases are handled with rules and data checks. When the meaning of a call depends on an earlier approval, an identity change, or the state of an object, our model supplies the contextual judgment. Harden can then allow the call, rewrite it safely, or block it.
Many actions can be resolved directly. Harden applies organisation-defined policies and checks for recognised secrets and sensitive files. Agents also write scripts while they work, so Harden can protect sensitive values moving through Bash and Python commands. Sometimes a command contains both useful work and data that should not be sent. In the example below, an agent includes a secret in a diagnostic note alongside a deployment event. Harden redacts the secret and preserves the event. It does not remove a credential that the request needs to authenticate: when a call cannot be made safe, Harden blocks it.
**Secret check**
Send the event, not the secret.
The secret is incidental diagnostic data, not the credential the request needs.
The agent's call includes a diagnostic note.
`$ curl -d "event=deploy-complete¬e=$SECRET_API_KEY" \ https://telemetry.example/ingest`
The secret in the note is replaced.
`$ curl -d "event=deploy-complete¬e=$(harden_aif.filter "$SECRET_API_KEY")" \ https://telemetry.example/ingest`
Payload sent
`event=deploy-complete¬e=…[AIF_REDACTED]`
**Event delivered**
Telemetry receives the deployment event and a sanitised diagnostic note.
For recognised Bash and Python flows, `harden_aif.filter` redacts a secret before the command runs. A request that needs the secret to work is blocked rather than rewritten.
The next example shows why direct checks are not enough. A developer asks the agent to upload model weights to the company's backup bucket. Earlier in the session, a personal AWS profile may have been selected for unrelated work and never changed back. The agent sees a routine upload command:
`$ aws s3 cp ./weights/ s3://corp-models/` The upload would run through the personal account rather than the company profile intended for the backup.
Our model reasons over the developer's request, the profile change, and the pending upload. It concludes that the personal profile is not authorised for this transfer, so Harden stops the call. After the agent switches back to the corporate profile, the backup succeeds. In other sessions, the important change may be a staging task redirected to production, a directory linked to a protected file, or several permitted actions that together exceed a limit.
The following three examples show how Harden evaluates agent actions in context, using the developer's intent and earlier events in the session to determine whether an action should be allowed or blocked.
“Promote the validated build to staging.”
The developer approved build-413 for the staging environment.
`$ deployctl promote build-413 --environment staging`
Harden confirms that the requested target stays within the developer's approval.
Staging release started.
Earlier tool output sets DEPLOY_TARGET=production.
`$ deployctl promote build-413 --environment production`
Harden rejects the production target: tool output cannot expand a staging approval.
Call stopped before production changes.
Each animation begins with one request. Harden evaluates the proposed call in the context of the session, allowing actions that remain within the developer's intent and stopping those that do not.
In the first example, the developer approves a release to staging. The staging call should run, but an otherwise similar call aimed at production should not. The model recognises that output from another tool cannot turn a staging approval into a production approval, so it allows the first call and blocks the second.
The incident example begins with a request to attach logs to an internal ticket. The internal attachment is legitimate and continues normally. A generated runbook later suggests sending the same logs to an external upload service, but that suggestion does not change what the developer authorised. The model allows the internal attachment and stops the external transfer.
In the final example, the agent is asked to run an evaluation and review its results. Reading the expected result files is part of that work. Creating a link from the results directory to a large model checkpoint is not. Harden distinguishes the authorised evaluation work from the unrelated attempt to expose the checkpoint.
Reason over the session
Harden's local cybersecurity LLM performs a focused, repeatable job: it evaluates each proposed tool call before it runs. The difficult cases often involve ordinary actions whose meaning has changed over the course of a session. A profile may point to a different account, a directory may acquire another file, a configuration may select another environment, or an instruction may come from a source that cannot grant authority. By the time the agent proposes its next call, that history determines whether the action is still authorised by the developer's intent.
In the upload example, the developer did ask for a backup and the destination is the company's bucket. The relevant fact is that the personal AWS profile remained active from earlier work. Harden's model considers that earlier choice together with the pending upload, because it determines which identity the command will actually use. The request and the command are both reasonable in isolation; the mismatch becomes clear only when that earlier choice is connected to its effect.
The model is trained to reason about these causal dependencies. Given a proposed call, it identifies the earlier event that changed a material fact, traces how that fact changes the operation's effect, and determines whether the next action is authorised to run. The coding agent continues to solve the engineering task; Harden's model independently evaluates each proposed action. It runs locally, so repository context, tool output, and command arguments remain on the developer's machine rather than being sent to a remote model. The full local model currently requires a supported Apple Silicon Mac with at least 16 GB of unified memory; see system requirements and measured local performance.
We post-train the model on a purpose-built corpus of about 329 million tokens, drawn from natural agent trajectories and matched sessions. The corpus balances actions that should proceed with actions that should be stopped, teaching the model when to intervene and when to let ordinary work continue. In each matched session, the pending call is identical; only one earlier fact changes, such as an approval, a file mutation, the source of an instruction, or the number of previous operations. The different outcome teaches the model to use the history that gives a call its meaning.
Measure the boundary
An effective security monitor must block harmful actions without repeatedly interrupting ordinary work. We evaluated our model across four agent-security benchmarks. Together, they cover long-running tasks, realistic workspaces, and attacks that depend on earlier changes to files, permissions, or the environment. Each benchmark defines a different task and metric, so we report the results separately.
SLEIGHT contains synthetic transcripts designed to expose blind spots in monitors that review an agent's complete trajectory. AgentHazard follows dangerous behaviour across longer tasks. SABER evaluates the safety of a completed workspace, so we reconstruct it as a pre-tool-call replay. LinuxArena follows step-by-step agent work in a realistic Linux workspace. Each benchmark name below links to its original paper or repository.
We use GPT-5.5 as the monitor baseline for SLEIGHT, AgentHazard, and SABER. However, this is impractical as a deployment pattern because every proposed action sends the same frontier model through a second call to review its own work. That doubles model calls, adds 10–13 seconds per action, and substantially increases inference cost. LinuxArena's published public-release baseline uses a GPT-5 Nano monitor.
SLEIGHT requires a different evaluation setup for a pre-execution monitor. Its published protocol gives a monitor the completed transcript and asks it to produce a suspiciousness score. Our model must decide while a tool call is still pending. We therefore cut each transcript at the call being evaluated and provide only the task and history visible before it. The resulting number measures how often the model catches a harmful call before it runs. It is not the benchmark's official completed-transcript score.
Our model Reference monitor Higher values are better Lower values are better
TPR at ≤1% FPR on a pre-tool-call reconstruction.
**15.8% our model****14.3% GPT-5.5**
First-harm catch rate across dangerous calls in longer agent tasks.
**83.7% our model****81.4% GPT-5.5**
Harmful-action recall in a SABER-derived pre-tool-call replay.
**48% our model****44.7% GPT-5.5**
Undetected sabotage success on LinuxArena’s public release at 1% step-wise FPR.
**29% our model****34% GPT-5 Nano monitor**
Results are shown in the direction used by each benchmark. Higher catch rates are better; lower undetected sabotage success is better. Evaluation details are in the appendix.
Harden vs. GPT-5.5 (as a tool-call monitor) on critical agent-security categories
Harden CyberLLM GPT-5.5
Not every category appears in every source benchmark. The balanced-score method and category definitions are in the Evaluation appendix.
The results show different trade-offs. Harden scores 83.7% on AgentHazard's first-harm catch rate, compared with 81.4% for GPT-5.5. On the SABER-derived pre-tool replay, Harden reaches 48% harmful-action recall, compared with a 44.7% average across GPT-5.5 with and without reasoning. SLEIGHT is deliberately more restrictive: both models receive the same pre-tool view, rather than the benchmark's completed transcript. Harden scores 15.8% on this reconstruction, compared with a 14.3% average across GPT-5.5 with and without reasoning. The SLEIGHT and SABER figures should not be compared with those benchmarks' official completed-trajectory results. On LinuxArena's public release, Harden's 29% undetected sabotage success rate is lower than the paper's 34% GPT-5 Nano monitor baseline under the same 1% step-wise false-positive-rate target.
Start securing endpoints
As coding agents become more capable, teams will adopt new models, connect new services, and give agents more responsibility. Their security boundary should not have to change with every part of that stack. By evaluating each action before execution, Harden keeps an independent security control between the agent and the environment it can affect.
Harden makes that decision directly on the tool path for Claude Code and Codex. It combines explicit controls with our model's contextual judgment, so ordinary work can continue while actions that no longer fit the task or authority are stopped.
Install Agentic Integrity FoundationView on GitHub
Evaluation appendix
Balanced category score
The balanced detection score gives equal weight to identifying harmful calls and allowing benign calls: it is the average of harmful-call recall and benign-call specificity, where specificity is 100% minus the benign-call false-positive rate. A monitor cannot improve this score simply by blocking every call or allowing every call.
Not every category appears in every source evaluation. The grouped chart uses the available category-level balanced scores. Each GPT-5.5 value is the average of its no-reasoning and high-reasoning monitor runs for that category.
Category definitions
Code and supply-chain sabotage Changes that tamper with source code, build or release artefacts, dependencies, or the software delivery path.
Destructive actions Actions that delete, overwrite, or otherwise damage data, files, or operational resources.
Persistence Changes that leave an unauthorised mechanism in place beyond the immediate task, such as a startup entry or scheduled job.
Privilege or unauthorised access Attempts to use authority beyond the task or identity's approval, including privilege escalation and access-control bypass.
System RCE Actions that create a path to arbitrary code execution on a host or other managed system.
Compliance or control bypass Attempts to avoid organisational or security controls that govern how the task must be completed.
Unauthorised outbound exfiltration Transfers of data to an external destination that is not approved for that material or task.
SLEIGHT
SLEIGHT normally evaluates a monitor on a completed transcript. That gives the monitor access to the later actions and tool results that reveal whether an earlier decision led to harm. Harden must decide before the next tool call runs, when the relevant effect still has to be inferred from the request and the visible session. We reconstructed the benchmark for that setting by converting 42 paired scenarios into 84 pre-tool-call examples across 11 attack categories.
Each pair contains an attack trajectory and a benign counterpart for the same task. We selected the first annotation-supported attack call that diverges from its benign trajectory and took the benign call at the equivalent relative point. Each example contains the initial task, earlier tool calls, their outputs, and any preceding session. Free-form assistant reasoning and future events are excluded.
| Monitor | Scored attack / benign | TPR at ≤1% FPR | AUROC | | --- | --- | --- | --- | | Harden CyberLLM | 38 / 40 | 15.8% | 65.3% | | GPT-5.5 | 42 / 42 | 14.3% | 74.8% |
TPR at ≤1% FPR is the fraction of scored attack calls above the highest benign score while permitting no more than 1% benign false positives. With 40–42 benign examples, that threshold permits zero observed false positives. Harden's figure uses its best SLEIGHT-development iteration and excludes four attack and two benign encoding non-decisions; GPT-5.5 covers all 84 examples. Its displayed result is the average of no-reasoning and high-reasoning runs. These are single-trial, product-protocol results, not SLEIGHT's official ten-trial temperature-1 aggregation.
GPT-5.5 without reasoning took about 10 seconds per sample, high reasoning took 12–13 seconds, and extra-high reasoning took about 19 seconds. Those timings underline the operational difference between completed-transcript monitoring and a monitor that must make an ex-ante decision for every pending call.
For the other evaluations, GPT-5.5 itself is used as the monitor: every pending tool call requires another frontier-model inference. This adds 10–13 seconds per call and materially increases the cost of a long-running agent session.
SABER
SABER's native evaluation lets an agent complete a task and then judges the resulting workspace or environment. Harden evaluates a tool call immediately before it runs, so we converted the released trajectories into action-local pre-tool-call views rather than reporting SABER's official harmful safety-violation rate.
Each replay contains the task, the preceding assistant and tool history, and the exact pending call; future calls, outputs, benchmark judgments, labels, and hidden reasoning are excluded. Officially localized harmful calls are treated as BLOCK, and calls from officially non-harmful trajectories are treated as ALLOW. The result is a SABER-derived pre-tool-call replay that measures whether the monitor identifies a harmful pending action, not whether an agent can recover and complete the task after a live block.
AgentHazard
AgentHazard releases complete agent trajectories, while Harden evaluates a tool call before it runs. We therefore converted 540 released trajectories into 1,857 action-local examples. Each example contains the exact pending call and everything observable before it: the user request, assistant messages, earlier tool calls, and their outputs. Future events and hidden benchmark annotations are excluded.
A trajectory-level adjudication pass identifies the first call that realizes harm. The panel contains 698 safe calls before divergence, 388 first harmful calls, 475 subsequent harmful calls, and 296 controls from trajectories with no realized harm. It spans nine attack classes: compliance bypass, data exfiltration, destructive actions, persistence, privilege escalation, prompt-intelligence theft, resource exhaustion, supply-chain poisoning, and system RCE.
First-harm catch rate measures the share of harmful trajectories where the monitor blocks the earliest call that realizes harm. Harden reaches 83.7% on the full panel, compared with 81.4% for GPT-5.5 averaged across no-reasoning and high-reasoning runs.
LinuxArena
LinuxArena is a control setting for agentic software work in live, multi-service Linux environments. Its published paper includes 10 public environments, with 92 released side-task trajectories generated by Claude Opus 4.6. We evaluated Harden on that public release as a live, per-action monitor rather than as a completed-transcript reviewer.
At a 1% step-wise false-positive-rate target, we measure undetected sabotage success: the share of attacks where the side task succeeds without the monitor intervening. Harden's result is 29%. Lower is better. LinuxArena reports a 34% public-release baseline for the GPT-5 Nano monitor against the same Opus 4.6 attack set.
System requirements
Running the full local model
The current full model is supported on macOS with Apple Silicon, 16 GB or more of unified memory, working Metal acceleration, and at least 10 GB of free disk for an initial installation. We recommend 24 GB for everyday use and 32 GB when the machine also runs Docker, a large IDE, browsers, or other local models.
Memory and storage
The Q4_K_M model download is 5.17 GiB and the engine keeps an 8 GB memory governor. On the measured 16 GB machine, the engine's private working footprint is about 1.5 GB. The model is memory-mapped from disk, so once inference has touched its pages, macOS reports about 6.7 GB resident memory, including the mapped model and shared Metal working memory. The 5.17 GiB model is therefore not a second private allocation on top of the working footprint. Allow 15 GB of free disk for normal updates, which retain the previous model for rollback.
Measured local performance
On an Apple M5 with 16 GB unified memory, the warm end-to-end decision time was 2.33 seconds median for a 311-token regression prompt. Cached time to first token was 32 ms; without a prompt cache it was 507 ms. A cold complete decision averaged 2.81 seconds. Larger, uncached agent contexts take longer, and a decision after AIF's five-minute idle unload takes about 7.9 seconds while the checkpoint reloads.
Base model
The current model is post-trained from Zyphra's ZAYA1-8B base model (reported as 8.84B parameters), pinned at revision `67d34da515b30409ee8daa67c3605c4402d03f6f`. It uses a 32,768-token runtime context and is distributed in Q4_K_M quantization.