Policy

See Trust and permission for the model. This page is the operational detail.

Write the baseline

cd ~/my-agent
hexaeight-activate add-policy --owner [email protected]

That produces the rows an ordinary agent needs. The full set, and why each exists:

principal	object	direction	why
[email protected]	*	inbound	the owner may sign in and reach this agent
<agent-name>	*	inbound	the router’s replies come back as this identity
[email protected]	op:*	outbound	workspace operations — without it sign-in works and nothing else does
[email protected]	editor:*	outbound	memory pane, browser and editor surfaces
<agent-name>	op:*	outbound	unattended work — skills and missions run as the agent
*	<agent-name>	outbound	engines call the router; the sender is engine:<name>, so this must be *
*	<peer>	outbound	only if you have peers — one row per external agent you call

Add one principal

./hexaeight-agent-linux-x64 hexaeight-agent.json \
    --add-rule '[email protected],*,inbound,allow'

For an external caller acting for a person, the principal is the hash:

SUB=$(printf '[email protected]' | sha512sum | cut -d' ' -f1)
./hexaeight-agent-linux-x64 hexaeight-agent.json --add-rule "${SUB},<agent>,inbound,allow"

Prove it

hexaeight-activate list-policy --subject [email protected]

This prints what the enforcer decides, not what is written down. A rule that is present but does not match reads as protection and is not.

A healthy baseline ends with a deliberate refusal:

inbound  [email protected]  ->  <agent>   DENY   ok

Three traps

op:* is needed twice — once for the owner, once for the agent itself. The agent’s row is the one always missed, and it only breaks skill runs, with bind said 404.

Never *,*,inbound,deny. It outranks everything else you wrote.

Vouching

./hexaeight-agent-linux-x64 vouch allow --caller <agent> --subject "$SUB"
./hexaeight-agent-linux-x64 vouch list

Loaded once at startup — restart after a change:

[byoa] vouch policy loaded: 2 rule(s)

Approved builds

Binaries gate on published hashes, fetched at runtime. A build whose hash is not listed is refused by peers, so withdrawing one is central and needs no redeployment.

Adding a hash later still reaches every machine, which is why the list — and not the tool — is where they belong.