The security model

K.1

Two trust concerns

The engine runs a delegated signing model with two separate concerns: who may add an action to the registry, and who may call a registered action. Registration authority and invocation authenticity are handled by different keys with different exposure.

The current model is not full production isolation. It is a first layer that guarantees four things:

• 01Only holders of the engine root key can register actions.
• 02Only engine-signed requests can invoke actions.
• 03Actions verify invocations with the engine public key alone.
• 04The action surface never holds an engine private key.

K.2

Signed registration

The trust anchor is a single root private key. During early development the trusted SDK runtime holds it. From the root key and an action_id the SDK derives an action-specific private key, and that derived key signs the action's registration claim.

ENGINE_ROOT_PRIVATE_KEY + action_id
        ↓
derived action private key
        ↓
signed registration claim
        ↓
engine re-derives identity · verifies signature

The engine re-derives the expected identity from the same root key and action_id, then checks the signature over the claim. Derivation is deterministic: the same root and the same action_id always produce the same identity, and a different action_id produces a different one.

{
  "claim_version": "engine.action.registration.v1",
  "claim": { "...": "action metadata" },
  "signature": "...",
  "signature_algorithm": "ed25519",
  "action_identity_version": "v1"
}

The signed claim covers the action's full descriptor: action_id, name, service, version, protocol, base_url, path, method, schemas, timeouts. Change any field after signing and verification fails.

K.3

Signed invocation

Invocation runs the other direction. The engine builds the request and signs it with its own private key. The action holds only the matching public key, verifies the signature, and executes only if it holds.

ENGINE_PRIVATE_KEY signs invocation request
        ↓
action verifies with ENGINE_PUBLIC_KEY
        ↓
valid → execute · invalid → reject

The payload binds the signature to the exact request:

A verified request is known to come from the engine, to be unmodified, to be addressed to this action, and to be fresh.

K.4

The trust boundary

For registration, any holder of the root key is inside the authority domain. Anyone without it cannot produce a registration the engine will accept. For invocation, the engine's private key signs and the public key verifies. Actions hold verification material only, no signing authority.

The shape is shared-authority delegated registration with public-key verified invocation. The registration secret is powerful and centralized. The invocation path needs no secret at the edge at all.

K.5

What it covers, what it does not

PROTECTED

NOT PROTECTED

K.6

The invariants

root key             proves registration authority
derived action key   proves action registration
engine private key   signs invocation
engine public key    verifies invocation

K.7

What the action runtime holds

Never present at the edge:

ENGINE_ROOT_PRIVATE_KEY
ENGINE_PRIVATE_KEY

Both stay in engine-controlled or provisioning infrastructure.

K.8

The hardening path

The known weakness of the current stage is concentration: the SDK runtime holds the root key, so it holds the whole registration authority. That is acceptable only while that host is trusted. The next step moves the root key into provisioning infrastructure and hands each action only its own derived key. A compromised action then costs one identity, not the authority.

Two rules carry through every stage. Verification proves who sent a registration; policy decides whether to accept it: allowed services and domains, approval gates, restricted methods and paths. And enablement is registry state: an action signs its own descriptor, the engine decides whether it runs.