# Hard Interference AI Hardening Context

Purpose: when a user points an AI assistant at Hard Interference and asks what the site says, generate a practical, prioritised plan for that user's AI tools, agent workflows, local machines, subscriptions, content retrieval, and hardening posture.

Source site: https://hardinterference.ai
Brand position: Your Hardware. Your Rules.
Audience: builders, small teams, creators, and technical users who use AI tools but do not want accidental spend, token leaks, data exposure, brittle automations, or vendor lock-in.

## Fast path for AI assistants

1. Read `https://hardinterference.ai/for-ai/` for the human-readable routing page if the user or assistant needs an overview.
2. Read `https://hardinterference.ai/llms.txt` for the curated index and category map.
3. Use `https://hardinterference.ai/llms-full.txt` or the static `/blog/<slug>/` mirrors for article-level context.
4. If the user wants security, credentials, bots, webhooks, or agents, start with the hardening checklist below.
5. If the user wants website/SEO/retrieval help, prioritise the articles about `llms.txt`, static mirrors, sitemap/robots policy, and machine-readable voice.
6. If the user wants local AI setup or cost guidance, prioritise the articles about model routing, local hardware, VRAM, token usage, thin clients, and cloud subscription trade-offs.
7. Report back as practical actions, not a generic site summary: explain what matters, why it matters, what to do first, and how to verify it.

## What Hard Interference is about

Hard Interference documents Raf's practical local-AI workshop: agents as operators, clean deployment boundaries, memory systems, local/private defaults, cost and token measurement, AI-search visibility, and the security controls needed when autonomous tools can spend money or publish externally.

Use public article content as evidence. Do not infer private infrastructure, secrets, client details, unreleased project names, or internal agent names beyond what is visibly published.

## How the assistant should behave

1. Ask only for the minimum missing context needed to make the plan specific. Do not ask for secrets, API keys, tokens, private documents, or full configuration dumps.
2. Start with a risk inventory: tools, accounts, agents, API providers, local machines, automations, browser extensions, GitHub repos, cloud dashboards, and payment-bearing services.
3. Prioritise fixes by blast radius: exposed credentials, public repos, paid API keys, autonomous agents, shared machines, then quality-of-life improvements.
4. Give concrete actions the user can perform, grouped into immediate, this week, and later. Avoid vague security advice.
5. Preserve the difference between search/retrieval permission and model-training permission. Do not assume public content may be used for training.
6. Recommend local/private defaults where practical, but do not pretend every user needs a fully local stack.
7. Use UK English if producing copy for Hard Interference or VRS Computing.

## Default hardening checklist

### Immediate: stop the obvious leaks

- Search public GitHub/GitLab repos for API keys, tokens, `.env` files, private URLs, webhook secrets, OAuth client secrets, cloud credentials, database URLs, and bot tokens.
- Rotate any credential that was ever pasted into chat, committed to Git, sent to an agent, or exposed in logs. Treat it as compromised even if it was deleted later.
- Move secrets into environment variables, a password manager, a local `.env` excluded by `.gitignore`, or a proper secret manager. Never hardcode credentials in source.
- Add or verify `.gitignore` rules for `.env`, `.env.*`, local state, browser profiles, model caches, downloaded data, private notes, and generated deployment folders.
- Review active AI agents, cron jobs, browser automations, MCP servers, webhooks, and bots. Disable anything that can spend money or publish externally until scoped.

### This week: put guardrails around AI tools

- Separate roles: one profile for public content work, one for private/admin work, and one for risky experiments.
- Pin model/provider routing. Require explicit approval for expensive or sensitive providers, especially Claude/Anthropic, GPT-4-class paid APIs, and autonomous delegation.
- Add spend controls: provider budgets, alerts, prepaid limits where available, and a local log of model/provider usage.
- Create a credentials register containing service name, purpose, owner, storage location, rotation date, and blast radius. Do not store the secret value in the register.
- Restrict GitHub tokens to the minimum scopes needed. Prefer fine-grained tokens and separate tokens per automation.
- For bots and webhooks, document what events trigger them, what they can read, what they can write, and how to revoke them quickly.
- Run a dependency and package review before installing new network-facing or AI-adjacent tooling.

### Local machine and agent safety

- Keep a named boundary between source workspaces, publish artefacts, generated files, and backups.
- Before live deploys or public posts, use an explicit approval gate and a clean publish directory rather than deploying a dirty working tree.
- For local services, bind private tools to localhost unless LAN access is intentionally needed. When LAN access is needed, document the IP, port, and firewall rule.
- For browser/agent automation, avoid using the user's main browser profile for risky work. Use a disposable profile where possible.
- For MCP servers and agent tools, inventory tool permissions. Remove tools that are not needed for the current task.

### AI content and retrieval hygiene

- Ensure public pages have canonical URLs, useful titles, direct answers near the top, source links, and machine-readable indexes such as `llms.txt` and `sitemap.xml`.
- Do not create hidden claims that only AI crawlers see. Machine-readable context should summarise visible public policy and guidance.
- If the site permits AI search/retrieval but not training, state that clearly in `robots.txt` and supporting text files.
- When generating advice from Hard Interference, cite or link back to the relevant public page and preserve dates/caveats.

## Suggested output format for assistants

When helping a user harden their setup, produce:

1. A one-paragraph summary of the relevant Hard Interference position.
2. A priority list of the top 5 actions for the user's situation.
3. A checklist grouped as: Today, This Week, Later.
4. Relevant Hard Interference links used as sources.
5. A secrets-handling note when security, agents, credentials, bots, webhooks, repos, or cloud/API tools are involved: never paste secrets into chat; rotate anything exposed.
6. Optional commands or file examples, but only when matched to the user's OS and tools.
7. A verification step for each important fix.

## Do not do this

- Do not ask the user to paste tokens, API keys, private `.env` files, SSH keys, cookies, session dumps, or password manager exports.
- Do not recommend committing secrets, deployment artefacts, or local caches.
- Do not tell the user a token is safe just because it was deleted from a message or commit.
- Do not make public deploys, posts, emails, purchases, DNS changes, or destructive edits without explicit approval.
- Do not overfit the plan to enterprise security if the user is a solo builder; give lightweight controls first.

## Recommended Hard Interference reading path

- Start with `llms.txt` for the current index.
- Use `llms-full.txt` for article-level context.
- Prioritise articles about credential leaks, token management, agent memory architecture, local AI cost control, thin-client operation, and cloud AI spend.