created 24 August 2026 · last modified 24 August 2026
the architecture
An action authorization plane for autonomous systems.
The 1,612-risk problem reduces to a small verb library. Ten control sets. Seven enforcement surfaces. One decision function: ALLOW / CONSTRAIN / VETO / ESCALATE / REVOKE. And upstream of all of it, a second gate: not whether the action is safe, but whether it is appropriate to the moment.
§01reference architecture
KTP defines a Policy Decision Point and a set of Policy Enforcement Points applied to agent actions, not just network or identity events. The PDP evaluates each attempted action against identity, intent, context, resource, trajectory, and policy. The PEPs sit at every surface where motion can occur: tool gateways, API gateways, data layers, identity layers, egress, and transaction systems.
The decision function returns one of five outcomes: ALLOW, CONSTRAIN, VETO, ESCALATE, or REVOKE. Telemetry from every decision flows to Splunk as the system of record; SOAR handles response when a constraint or veto fires.
pdp / pep flow
Agent Runtime
↓
Action Request
↓
Should Gate — Tamed Autonomy: Should · Intent · Normative
↓
KTP Policy Engine (PDP)
↓
Decision: Allow / Constrain / Veto / Escalate
↓
PEP at Tool / API / Data Layer
↓
Execution or Block
↓
Telemetry → Splunk
↓
SOAR → Response if needed
the trust-model shift
today
tomorrow
Authenticate
Authenticate
Authorize
Evaluate Intent
Execute
Validate Context
Enforce Action
Monitor Trajectory
§02the should gate
Everything above answers one question: can the agent act here. There is a second question the control plane has to answer, and almost no stack does: should it act, right now. An agent can be fully authorized, the environment calm, every control green, and still be one step from the wrong action for the moment. A comms agent cleared to send the quarterly newsletter, an hour after the layoffs were announced. Authorized is not the same as appropriate.
The should gate runs upstream of the policy engine, where the flow diagram places the Tamed Autonomy layer. It is conjunctive, evaluated per moment-category: an action clears it only if it passes both a physics check and a normative check.
the rule
(W_phys ≤ J_phys) AND (W_norm ≤ J_norm)
W is the weight of the moment; J is the judgment the agent has earned for a moment like this. W is not a single number. It splits in two. W_stability is the part telemetry can read: heat, momentum, an open incident, a change-freeze window. W_normative is the part with no signal: a layoff, a regulated quiet period, a response out of all proportion. The physics reads the first. It cannot read the second.
two enforcement tiers
De-automation
ESCALATE
Removes automaticity, not capability. The agent can still do the thing. It just cannot do it silently, on autopilot, in a moment that calls for a hand on the rail.
Propriety veto
VETO
A hard refusal that no risk score and no admin can override. Reserved for the slow, settled red lines: data sovereignty, regulatory prohibition. This is the Soul dimension on the should axis.
what you can build, and what needs a human
The normative half is not one job. Sort each appropriateness fact by whether it leaves a telemetry signature and whether it is slow and settled or fast and novel. Three of the four corners can be built. The fourth, a fact that is both fast and signatureless, has no physical home and has to be routed to a person.
a layoff an hour ago, active litigation, a disproportionate response
slow
Policy
standing entitlements, baked-in action limits
Inject
data sovereignty, a standing regulation
the partner layer
KTP is the engine that can act on a should. It enforces a normative verdict by de-automating or vetoing. It does not author one. That judgment is supplied by Tamed Autonomy, the work of Robin Martherus: authenticate the purpose, not just the identity. KTP supplies the gate; Tamed Autonomy supplies the judgment. The two-gate architecture, can and should, is the subject of a piece the two of us are writing together.
§03enforcement surfaces
Seven places to put a Policy Enforcement Point. The Tool Gateway is the load-bearing one: if you do nothing else, centralize tool access, enforce policy there, log everything. That alone covers a large portion of the top risks.
PEP 1
Agent runtime / orchestrator
Where agents plan and execute (LangChain, LlamaIndex, custom).
The 337 Core + Strong KTP risks cluster tightly. You do not need 337 controls. You need ten. Each set names what it covers, what you build, the decision it produces, examples, and where it lives in the stack. Control Set 1 is open by default; the rest are collapsed.
covers
1, 2, 4, 8 · data exfiltration, tool misuse, API actions, data poisoning
what you build
A single choke point for all agent actions.
decision
ALLOW / CONSTRAIN / VETO / ESCALATE
examples
Block DB queries outside allowed scope. Restrict file paths. Validate API parameters. Deny external data export. Rate-limit tool execution.
Evaluates identity, intent, context, resource, trajectory, and risk per attempted action.
decision
ALLOW / CONSTRAIN / VETO / ESCALATE / REVOKE
examples
Continuous, action-level enforcement. Authorization stops being a one-time decision.
stack
KTP policy engine / Splunk (telemetry) / SOAR (response) / IAM and ZTNA (context).
§05the verb library
People classify AI risk by nouns: misinformation, privacy, bias, autonomy, fraud. KTP classifies by verbs. The risk universe is large; the control vocabulary is small. The verb is where governance becomes enforceable, but the action tuple is what makes it safe. For the empirical case behind this collapse, see risks.
For AI, cognition becomes kinetic when inference changes what the system or another actor can do next.
§06least trajectory
Classic security gives the user the least privilege necessary. But autonomous agents create a new problem: even with least privilege, an agent can combine allowed actions into an unsafe sequence. Each verb may be acceptable. The chain may not be.
So KTP adds a second constraint above least privilege: least trajectory. Not only what permissions does the agent have, but what sequence of movements is the agent allowed to take. Trust attaches to paths, not actors. An agent may be trusted at step 1 and untrusted by step 5.
a chain that no single verb would block
read→infer→retrieve→combine→export→notify
Each action passes individually. The trajectory exfiltrates a person.
Agent security is not only permission management. It is sequence governance.
Perkins, C. (2026, May 6). An action authorization plane for autonomous systems. Kinetic Trust Protocol. https://kinetic-trust-protocol.net/enterprise/architecture
Plain text
Chris Perkins, "An action authorization plane for autonomous systems," Kinetic Trust Protocol, https://kinetic-trust-protocol.net/enterprise/architecture (accessed May 6, 2026).