How it works

You do not have to read any of this to use ArmorIQ. Install it and it works. This page is for when you want to know what it is actually doing.

1. Every action gets checked before it runs

An AI coding assistant does not just write text. It reads your files, edits them, runs shell commands, and calls out to the internet. Each of those is a tool call, and each one is a moment where something can go wrong.

ArmorIQ sits between the assistant and your machine. Before a tool call runs, it is checked against your rules, and it comes back with one of four answers.

Read src/app.tsreads a file inside the workspace

policy check

✓Allow

rule: reading inside the workspace is allowed

Edit .env.productionwrites a protected path

policy check

⏸Hold

rule: ask before touching production config

Bash rm -rf ./distdeletes a folder

policy check

✕Deny

rule: never delete without approval

• ✓ Allow
• ⏸ Hold
• ✕ Deny

A fourth decision, Error, appears when the check itself could not complete. It is shown as an error rather than quietly treated as an allow.

Allow and the action runs, as normal. Hold and it pauses for you to approve, which is the setting most people want on the things they care about. Deny and it never runs at all.

You control how strict this is. Everything your rules do not name falls through to a single setting, which you can leave permissive while you watch what your assistant actually does, then tighten once you know. Writing rules covers that choice.

2. Every call is recorded, in order

A session is one stretch of work with your assistant. ArmorIQ records each call in that session, what was decided, and how long it took.

18 calls13 allow3 hold2 deny

Read package.jsonGrep "createUser"Read src/auth/session.tsEdit src/auth/session.tsBash npm testRead .env.localRead .env.localEdit src/db/schema.sqlBash npx prisma migrateBash npx prisma migrateWebFetch api.stripe.comRead src/billing/plan.tsEdit src/billing/plan.tsBash npm testBash rm -rf node_modulesBash git statusBash git commitBash git push origin main

Hover a call above. Repeated pairs are a Hold that you approved, then the call running.

• ✓ Allow
• ⏸ Hold
• ✕ Deny

This is the part people find most useful early on, and it has nothing to do with blocking. It answers the question you cannot otherwise answer: what did it actually touch? When a test starts failing or a file changed and you are not sure why, the session is the receipt.

3. The week tells you where to put a rule

One session tells you what happened. A few weeks tell you what keeps happening, and that is what you write rules against.

102 of 1403 calls needed a human or were stopped.

194

Mon

259

Tue

205

Wed

339

Thu

295

Fri

64

Sat

47

Sun

Hover a day for its breakdown.

• ✓ Allow
• ⏸ Hold
• ✕ Deny

Bar segments are drawn with a minimum height so a single Deny is never invisible next to hundreds of Allows. The numbers in the tooltip are the real counts.

The useful signal is the thin band on top. Hundreds of allowed calls are noise. The handful that needed you, or that got stopped, are where your attention belongs.

What ArmorIQ never does

The numbers above are the ones that were recorded, and nothing else. If telemetry did not arrive, you see "unavailable" rather than a confident zero, and a session with no recorded calls says so instead of showing an empty dashboard that looks like a quiet day. That matters more than it sounds. A security tool that shows you a reassuring blank screen when it is actually broken is worse than no tool, because you stop looking.