Halo Agent Skills

A bundle of Agent Skills that let an AI agent help users interact with Glasswall Halo — protecting files, configuring policies, and generating integration code — with zero prior knowledge of Halo's APIs.

Agent Skills is an open standard (originally from Anthropic, adopted across Claude Code, Cursor, Gemini CLI, GitHub Copilot, OpenAI Codex, Goose, OpenCode, and others). These skills are vendor-neutral — a skill is just a SKILL.md file plus supporting references and scripts in a folder, which any compliant agent can load.

About Glasswall and Halo

Glasswall is a cybersecurity company specialising in file security — protecting organisations from file-borne threats without relying on signature-based detection. Its core technique is Content Disarm and Reconstruction (CDR), which reconstructs every file to a safe baseline; both known and novel threats are removed because the engine never has to recognise them.

Halo is Glasswall's file security platform — a deployable service that exposes APIs for protecting files at scale, validating XML, running an ICAP server, and monitoring cloud storage (SharePoint, OneDrive, Outlook) so threats are removed the moment files land. CDR is its primary protection capability. Customers deploy Halo into their own infrastructure and call its APIs from their applications, web proxies, or document ingestion pipelines.

What these skills do

Three skills, each covering a high-value Halo workflow:

Skill	What it does	Who uses it
halo-protect	Protects an actual file via Halo's synchronous v3 CDR API — submits the file, retrieves the rebuilt version and analysis report, surfaces the verdict. The agent executes Halo's protection pipeline on user-provided files.	Anyone who has files to protect on-demand
halo-policy-config	Configures a running Halo deployment via its admin APIs — engine policies, ICAP profiles, XML validation policies, storage monitors (SharePoint/OneDrive/Outlook). The agent executes API calls.	Halo admins doing post-setup configuration
halo-workflow-integration	Generates integration code in Python, JavaScript, C#, curl, or any language — for customer apps that call Halo's APIs as part of an ingestion or processing workflow. The agent writes code.	Developers adding Halo to their own application

Success criteria

1. A user can ask the agent to protect a specific file (or batch) and have it submitted to Halo, with the rebuilt file and analysis report returned, all without touching the API directly.
2. A user can request a policy change in natural language with zero knowledge of Halo APIs and have the agent execute it.
3. A user can request a new workflow integration in natural language with zero knowledge of Halo APIs and have the agent produce working code.

None of the three should require the user to consult API docs.

Layout

halo-agent-skills/
├── README.md
├── .env                            # optional, auto-loaded if present (gitignored) — see Configuration
└── skills/
    ├── halo-protect/
    │   ├── SKILL.md                 # entry point — agent reads this first
    │   ├── references/              # progressive-disclosure deep references
    │   │   ├── auth.md
    │   │   ├── api.md
    │   │   └── errors.md
    │   ├── examples/
    │   │   └── policy-sanitise-all.json
    │   └── scripts/                 # one helper, four interchangeable runtimes
    │       ├── halo_cdr.py          #   Python (reference) — needs `requests`
    │       ├── requirements.txt
    │       ├── halo_cdr.sh          #   bash + curl
    │       ├── halo_cdr.js          #   Node 18+ (built-in fetch)
    │       ├── package.json         #     declares "type": "module" for .js
    │       ├── HaloCdr.cs           #   .NET 8+ (BCL only)
    │       └── HaloCdr.csproj
    ├── halo-policy-config/
    │   ├── SKILL.md
    │   ├── references/
    │   │   ├── auth.md
    │   │   ├── engine-policy.md
    │   │   ├── icap-profile.md
    │   │   ├── xml-validation-policy.md
    │   │   ├── storage-monitors.md
    │   │   ├── content-management-flags.md
    │   │   └── api-routing.md
    │   ├── examples/                # ready-to-adapt JSON policy bodies
    │   │   ├── engine-policy-strict.json
    │   │   ├── engine-policy-balanced.json
    │   │   ├── icap-profile-default.json
    │   │   └── xml-policy-default.json
    │   └── scripts/                 # two helpers, four interchangeable runtimes each
    │       ├── apply_policy.py      #   Python (reference) — needs `requests`
    │       ├── apply_policy.sh      #   bash + curl
    │       ├── apply_policy.js      #   Node 18+
    │       ├── ApplyPolicy.cs       #   .NET 8+
    │       ├── ApplyPolicy.csproj
    │       ├── create_storage_monitors.py
    │       ├── create_storage_monitors.sh
    │       ├── create_storage_monitors.js
    │       ├── CreateStorageMonitors.cs
    │       ├── CreateStorageMonitors.csproj
    │       ├── requirements.txt
    │       └── package.json
    └── halo-workflow-integration/
        ├── SKILL.md
        ├── references/
        │   ├── auth.md
        │   ├── sync-cdr-api.md
        │   ├── async-cdr-api.md
        │   ├── xml-validation-api.md
        │   ├── legacy-v2-api.md
        │   ├── error-handling.md
        │   └── language-guide.md
        └── templates/               # working starter code
            ├── python/
            │   ├── sync_rebuild.py
            │   ├── async_rebuild.py
            │   └── validate_xml.py
            ├── javascript/
            │   ├── sync_rebuild.js
            │   └── async_rebuild.js
            ├── csharp/
            │   └── SyncRebuild.cs
            └── curl/
                └── examples.sh

Each SKILL.md has YAML frontmatter (name, description) so the agent surfaces the right skill based on what the user is asking for. Reference files are loaded on demand, not all at once — the agent reads only the files relevant to the current task. This keeps the context window lean.

Installing

The skill folders themselves are tool-agnostic. Where you copy them depends on which agent you're using — each tool defines its own skills directory. Check your tool's docs for the exact path; the agentskills.io client list links to the skills documentation for every supported tool.

For Claude Code, the directory is .claude/skills/ (project) or ~/.claude/skills/ (user). Example:

# POSIX
TARGET=/path/to/your/project
mkdir -p "$TARGET/.claude/skills"
cp -R skills/halo-protect                   "$TARGET/.claude/skills/"
cp -R skills/halo-policy-config         "$TARGET/.claude/skills/"
cp -R skills/halo-workflow-integration  "$TARGET/.claude/skills/"

# Windows / PowerShell
$target = "C:\path\to\your\project"
New-Item -ItemType Directory -Force "$target\.claude\skills" | Out-Null
Copy-Item -Recurse -Force ".\skills\halo-protect"                   "$target\.claude\skills\"
Copy-Item -Recurse -Force ".\skills\halo-policy-config"         "$target\.claude\skills\"
Copy-Item -Recurse -Force ".\skills\halo-workflow-integration"  "$target\.claude\skills\"

For other tools, swap .claude/skills/ for the directory your tool uses. The skill content does not change.

Using

Once the skills are installed, just describe what you want in plain English to the agent. Examples:

"Clean ./quarterly-report.docx with Halo and put the rebuilt copy in
./clean/, applying our strict-pdf policy."

→ halo-protect activates. The agent confirms the operation, runs the wrapper, surfaces the analysis report and x-processing-status, and tells you where the rebuilt file landed.

"Create a strict engine policy in Halo at https://halo.example.com that
disallows macros in Office documents and blocks executables in archives,
and call it 'financeStrict'."

→ halo-policy-config activates. The agent reads references/engine-policy.md and examples/engine-policy-strict.json, drafts the API call, shows it for confirmation, then executes.

"Add Halo CDR to my Express upload handler. Files come in as multipart and
I want them sanitised before I save them to S3. Use my company's 'balanced'
policy."

→ halo-workflow-integration activates. The agent reads references/sync-cdr-api.md and the JavaScript template, generates a working Express middleware, and walks the user through wiring it in.

The user does not need to know that "ICAP" is a thing, that storage monitors are bound to engine policies, or that v3 is preferred over v2. The skill encodes that knowledge.

Configuration

The skills read these environment variables at runtime (the agent will prompt if they're missing):

$env:HALO_BASE_URL = "https://halo.customer.example.com"
$env:HALO_TOKEN    = "<bearer-jwt>"
# Or, instead of HALO_TOKEN:
$env:HALO_BASIC_AUTH = "username:password"

There is no Glasswall-hosted public Halo URL — every customer deployment has its own.

Using a .env file (recommended for persistent / agent-agnostic setup)

Shell-set env vars are session-scoped and may appear in commands the AI runs while it works. If you'd rather not re-export them each session — or not have credentials surfaced in displayed commands — drop them in a .env file. The wrappers look in two locations (first match wins): ./.env in your current working directory, or ./.claude/.env (the convention used by this skill bundle — keeps Claude-related config in one folder).

HALO_BASE_URL=https://halo.customer.example.com
HALO_TOKEN=<bearer-jwt>
# Or, instead of HALO_TOKEN:
HALO_BASIC_AUTH=username:password

All the wrappers (scripts/halo_cdr.{py,sh,js,cs}, scripts/apply_policy.*, scripts/create_storage_monitors.*) load .env automatically at startup. The loader does not override variables already set in the environment, so a shell export, a settings.local.json env block, or CI secrets still win. Behaviour:

You have…	What happens
Just env vars set in shell / agent	.env is absent — wrappers use the env vars. No change from before.
Just .env present	Wrappers read it and populate HALO_BASE_URL / HALO_TOKEN etc.
Both	Existing env wins; .env only fills in what's missing.

.env is a simple KEY=VALUE format — # starts a comment, surrounding double or single quotes are stripped, no variable expansion. Keys must match ^[A-Za-z_][A-Za-z0-9_]*$; anything else is silently skipped. Add .env to your .gitignore — these are credentials.

See skills/halo-protect/references/auth.md ("If you persist credentials to a file") for permissions and storage guidance — chmod 600 on POSIX, lock the NTFS ACL on Windows, keep the file out of cloud-synced folders. .env is exactly the kind of file that guidance is meant to cover.

This makes the skills agent-agnostic: works the same under Claude Code, Cursor, Gemini CLI, manual CLI runs, or CI — no tool-specific config required.

What's intentionally not here

• Halo deployment / installation — initial Halo setup involves SSH-ing into a VM through a hypervisor and is out of scope for an agent running on the user's endpoint. Skills handle the post-deploy config + integration use cases instead.
• Processing-log analysis — logs sit in the Halo database and aren't reliably API-reachable, so this is deferred until there's an API surface for it.
• Anything beyond the public API surface — the skills are built strictly from Halo's published API contract at api.docs.glasswall.com. They will run against any Halo deployment a customer has been given access to.

Contributing

Skills are markdown — edit and reload. The structure to maintain:

• Keep SKILL.md short. It's the entry point; deep content goes in references/.
• Reference files should be loadable independently; cross-link with relative paths.
• Examples in examples/ and templates/ should be runnable, not pseudocode.
• When adding a new endpoint or schema, update the relevant reference file plus the SKILL.md "Reference files" table.

Licence

Released under the Apache Licence 2.0. See LICENSE for the full text and NOTICE for attribution.