KTP/
github ↗
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.

signal
no signal
fast
Automate
incident state, change-freeze window, error spike, market volatility
Route to a human
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).
controlsintent validation, trust tiering, delegation limits.
PEP 2critical
Tool gateway layer
DB, APIs, shell, browser, file systems, MCP. The most important new choke point.
controlsaction authorization, parameter validation, rate limiting, boundary enforcement, veto.
PEP 3
API gateway
Outbound service calls and internal microservices.
controlspurpose-bound access, identity propagation, scope enforcement.
PEP 4
Data access layer
RAG retrieval, databases, object storage.
controlssensitivity-aware access, query constraints, exfiltration checks.
PEP 5
Identity / delegation layer
Agent identity, human-to-agent delegation, service accounts.
controlsscoped delegation, time-bound authority, revocation.
PEP 6
Egress / network boundary
Outbound traffic and data movement.
controlsdestination validation, volume thresholds, anomaly detection.
PEP 7
Transaction / actuation layer
Payments, provisioning, infra changes, physical systems.
controlsapproval workflows, blast-radius limits, rollback.

§04control sets

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.
stack
Custom gateway + API layer / Splunk telemetry / SOAR response.
covers
1 · unauthorized data access and exfiltration (the #1 risk)
what you build
Classify data, enforce access context, block export to unknown destinations, limit query scope.
decision
IF data_sensitivity = HIGH AND destination = external → VETO
examples
Sensitivity-aware retrieval. Cross-tenant exposure checks. RAG leakage controls.
stack
Splunk (signals) / ISE / Entra (identity context) / tool or API gateway (enforcement).
covers
3 · credential and delegation abuse
what you build
Scoped delegation, time-bound permissions, action-level authorization.
decision
User delegates read-only analytics; agent attempts write or delete → VETO
examples
Over-scoped credential prevention. Human to agent delegation guardrails. Agent chaining limits.
stack
Cisco ISE / Entra (identity) / KTP layer (policy) / Splunk (logs).
covers
5 · autonomous transaction execution
what you build
Transaction limits (amount, rate). Approval thresholds. Anomaly detection.
decision
IF transaction_amount > threshold → ESCALATE to human
examples
Fraud prevention. Purchase approvals. Provisioning checks. Financial action review.
stack
Splunk (detection) / workflow system (approval) / API layer (enforcement).
covers
6 · multi-agent propagation
what you build
Limit agent spawning, restrict delegation depth, enforce workflow boundaries.
decision
IF agent_chain_depth > 2 → VETO
examples
Agents spawning agents. Uncontrolled chaining. Recursive execution.
stack
Runtime orchestrator / KTP policy engine / Splunk (logs).
covers
7 · high-speed automated attacks
what you build
Requests per second limits. API call throttling. Anomaly detection.
decision
IF rate > baseline + n·σ → CONSTRAIN
examples
AI-driven recon and exploitation. Lateral movement automation. Credential stuffing.
stack
Cisco + gateway (network / API) / Splunk (detection).
covers
1, 9 · data exfiltration, external communication misuse
what you build
Destination allowlists, data volume thresholds, external comms validation.
decision
IF destination ∉ allowlist → VETO
examples
Phishing prevention. Spam containment. Misinformation distribution at scale.
stack
Cisco Umbrella / Secure Access / ThousandEyes (visibility) / Splunk (detection).
covers
10 · loss of control, runaway agents
what you build
Revoke agent tokens, disable tool access, isolate execution environment.
decision
ON containment trigger → REVOKE all tokens, halt runtime.
examples
Infinite loops. Uncontrolled execution. Inability to stop. Blast-radius bounding.
stack
SOAR (containment trigger) / identity (revoke) / runtime (stop).
covers
All buckets
what you build
Log every action: agent → action → tool → data → destination → decision → outcome.
decision
(observational; feeds the PDP, the Splunk SoR, and the audit trail)
examples
Forensic reconstruction. Delegation chain attribution. Runtime policy decision evidence.
stack
Splunk = system of record. SOAR = response.
covers
All buckets · this is the KTP core.
what you build
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.

the action tuple
agent+verb+object+channel+context+consequence+constraint
Verbs expose the control surface. Context determines the constraint.
execution verbs
what the agent does in the world
readwritesenddeleteexecutedelegatepurchasetransferimpersonateescalateexfiltrate
intelligence verbs
what the agent does in cognition
inferclassifyrankcorrelatesummarizeprofilescorerecommendpredictretain
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
readinferretrievecombineexportnotify
Each action passes individually. The trajectory exfiltrates a person.
Agent security is not only permission management. It is sequence governance.
next doors

Risks

The empirical case. 1,612 MIT risks scored. The heat map, the matrix, the bimodal distribution.

Roadmap

Five phases from visibility to governance. The Tool Gateway as the headline.

CISO

Eleven reasons in CISO terms. The not-my-risk boundary. Budget justification frame.

Home Grown

The agents you didn't buy, and the ones you didn't register. Composite intent and the Declare/Emit/Accept conformance seam.

How to cite
APA 7th ed.

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).