Why policy for agents must be signed.

Most teams reach for agent governance and start with the rules: what can this agent touch, which tools, which data. That is the right content. But there is a question underneath it that decides whether any of it means anything: when the agent applies a policy, how does it know the policy is yours?

Without an answer, you have built governance on trust in a transport. And transports get compromised.

The threat is the gap between authoring and applying

Policy is written in one place and enforced in another, often many others: dev containers, CI runners, MCP hosts, automation nodes. Between those two points, a policy file travels. Anywhere along that path it can be modified: a man-in-the-middle on the network, a poisoned cache, a tampered artifact in a registry, a well-meaning script that "fixes" a value.

If the only check is "did the file arrive," then a single altered byte (a deny flipped to allow, a secret pattern removed from the block-list) sails straight through. The agent enforces the attacker's policy and reports success.

The danger is not a missing policy. It is a present, plausible, slightly wrong one that nobody can detect.

Signing turns "it arrived" into "it is authentic"

A signed policy bundle carries a cryptographic signature over its exact contents, produced with a key only the authoring side holds. The environment verifies that signature before applying anything. Now the check is not "did bytes arrive" but "are these the exact bytes the security team signed, unchanged." Tamper with one character and verification fails.

This buys three concrete properties:

1. Integrity. The policy applied is byte-for-byte the policy authored.
2. Authenticity. It came from the holder of the signing key, not from whoever could write to the channel.
3. Verifiable evidence. Because the signature is over a known hash, the report an environment sends back can be checked against the exact policy it claims to have applied.

Node-initiated pull, not central push

Signing answers is this authentic. Distribution answers how does it get there safely. The instinct is a central controller that pushes policy to every environment, which means that controller needs inbound network access to all of them. In a security product, that is precisely the connectivity you do not want to require.

So invert it. The environment runs a node that initiates the pull. It fetches the signed bundle and a signed pull index, verifies the trust fingerprint, checks that the bundle is bound to this target and that the sequence number only moves forward, then applies locally. Oktsec Control publishes; the node reaches out. There is no inbound path into the customer environment at all.

Air-gap is the same mechanism, not a special build

Here is the payoff of putting verifiability in the artifact rather than the connection: the most restrictive environments stop being a separate product. A signed bundle does not care whether it crossed a network or a USB drive. In an air-gapped setting, the same artifact is carried through controlled handoff, and the node verifies it the same way. Sequence checks still prevent rollback; signatures still prove authenticity. High-security environments get the normal path, offline.

The principle

Put trust in artifacts you can verify, not channels you have to defend. Sign the policy so authenticity travels with it, let environments pull and verify themselves so you need no inbound access, and keep the signed hash so the evidence coming back can be checked against the exact rules that were supposed to be in force. That is the whole chain, authoring to apply, with no link you have to take on faith.

This is how Oktsec Control distributes policy: signed bundles, node-initiated pull, verified evidence. See Oktsec Control →