A runtime policy tells the sensor to watch — or block — a specific kernel behavior: a file being opened, a binary executing, an outbound connection. Author them at Dashboard → Runtime → Enforcement. Every sensor pulls the enabled set and attaches the hook within ~30 seconds — no restart. There are two ways to write one: the builder or the AI assistant.

​
The builder

A policy has four parts:
FieldWhat it does
Name / descriptionIdentify the policy.
HookThe kernel behavior to watch — see Hooks.
ActionMonitor records the event (audit); Block stops the operation inline (enforce). Block is only available on blockable hooks and needs kernel 5.4+.
Match (optional)Narrow to specific paths / binaries / values — see Match conditions. Omit to match every event on the hook.
Namespace (optional)Limit the policy to one Kubernetes namespace.

​
Hooks

The hook is what the sensor watches. Pick one per policy.
CategoryWatchesCan block?
FileA file is opened / read — sensitive paths (/etc/shadow, SSH keys), file-integrity monitoringYes
ProcessA binary is executed — e.g. nsenter, nc, sudoYes
PrivilegeA Linux capability is requested — privilege use / escalationYes
Privilegesetuid — a process changes its user idNo
NetworkOutbound connection (egress), inbound connection (ingress), or connection teardownNo
Syscallptrace — debugging or process injectionNo
Blockable hooks (File, Process, Capability) can Monitor or Block; the rest are monitor-only.

​
Match conditions

A match narrows the policy to the events you care about — a file path, a binary name, a value. Choose an operator and one or more values:
OperatorMatches
Prefixvalue starts with … (e.g. path Prefix /etc/)
Postfixvalue ends with … (e.g. Postfix .pem)
Equal / NotEqualexact match / everything except
In / NotInany of a list / none of a list (e.g. binary In [nsenter, nc])
Leave the match empty to fire on every event for that hook.

​
Monitor vs. block

  • Monitor (audit) — the event is recorded and appears in Runtime → Events. Nothing is blocked. Start here.
  • Block (enforce) — the operation is stopped inline (kernel 5.4+, blockable hooks only). Blocked events appear in Runtime → Enforcement, marked enforced.
Roll a policy out in Monitor, confirm it matches what you expect (and nothing legitimate), then switch it to Block.

​
AI assistant

Rather not hand-build it? Describe the policy in plain English and TigerGate AI drafts it — choosing the hook, action, and match for you:
“Alert whenever anything reads /etc/shadow”
“Block nsenter and nc from executing in the payments namespace”
Review the generated policy (hook / action / match) and save. The assistant only ever produces a single policy and only uses supported hooks.

​
Examples

GoalHookMatchAction
Alert on reads of /etc/shadowFile openpath Prefix /etc/shadowMonitor
Block breakout tools in paymentsProcess executionbinary In [nsenter, nc, socat]Block · namespace payments
Flag SSH-key accessFile openpath Postfix /.ssh/id_rsaMonitor
Watch egress from the db workloadOutbound connection—Monitor · namespace db
Matches land in Runtime → Events (everything) and Runtime → Enforcement (policy-touched — denied when blocked, audit when observed). See Runtime Agent for the sensor itself.