RFC: Endpoint Sensor / Kinetic Layer for Policy Self-Modification Detection (RSAC Gap 1)

[MoltyCel]

Background

RSAC 2026 identified three critical gaps in agent identity frameworks.
MolTrust closes Gap 2 (delegation) and Gap 3 (ghost agents) this week.

Gap 1 remains open across all vendors including us:

An authorized agent modifies the policy governing the agent's own behavior.
Every identity check passes. The action is authorized. Nobody detects it.

The Problem

MolTrust operates at the identity/authorization layer:

• W3C DID (who is the agent)
• AAE (what is the agent allowed to do)
• Trust Score (how has the agent behaved)

What we cannot see: what the agent actually does at runtime on the endpoint.
Detecting policy self-modification requires a kinetic layer —
process-tree monitoring, file change detection, or equivalent.

What We're Looking For

Two possible approaches:

Option A — Integration with existing endpoint sensors
If you're building or operating an endpoint sensor / EDR that can track
agent process activity, we'd like to explore how MolTrust trust scores
and AAE constraints could feed into your detection logic.

Use case: Agent with AAE actions_denied: ["policy.modify"] triggers
a file write to a security config → your sensor fires → MolTrust records
a policy_violation_attempt IPR.

Option B — Test environment / honeypot
We'd like to build a controlled test environment where a MolTrust-registered
agent deliberately attempts policy self-modification.
Looking for partners who can provide:

• Process-level monitoring for Python/Node.js agents
• File integrity monitoring
• Or equivalent observability tooling

What MolTrust Provides

• W3C DID + VC for the test agent
• AAE with explicit actions_denied: ["policy.modify", "config.write"]
• IPR recording for every agent action
• Trust Score that degrades on violation detection
• Open source reference implementation

How to Collaborate

Comment below or reach out at security@moltrust.ch

Related:

• Protocol WP v0.6.1: https://moltrust.ch/whitepaper
• RSAC blog post: https://moltrust.ch/blog/rsac-2026-three-gaps.html
• @moltrust/verify: https://www.npmjs.com/package/@moltrust/verify

[HaraldeRoessler]

Offering: K8s-based test environment for Option B

I run a production Kubernetes cluster and would be happy to provide an isolated test environment for this.

Proposed setup

Infrastructure:

• Dedicated namespace (moltrust-test) on a Hetzner K8s cluster
• Falco (open-source, CNCF graduated) as the endpoint sensor — detects syscall-level activity: file writes, process spawning, config modifications, privilege escalation
• Webhook bridge: Falco alert → MolTrust API to record policy_violation_attempt IPR

Test scenario:

1. Deploy a MolTrust-registered test agent as a K8s Pod
2. Agent has AAE with actions_denied: ["policy.modify", "config.write"]
3. Agent deliberately attempts to write to a mounted security config (e.g. /etc/agent-policy.yaml)
4. Falco detects the file write at the syscall level and fires a webhook
5. Webhook calls MolTrust IPR endpoint to record the violation
6. Trust score degrades — observable via /reputation/query/{did}

Architecture:

[Agent Pod] --syscall--> [Falco DaemonSet] --webhook--> [Bridge Pod] --POST--> MolTrust /vc/ipr/submit
                              |
                         Falco Rule:
                         "write to /etc/agent-policy.*
                          by container with label
                          moltrust-agent=true"

Why Falco fits

• Operates at the kernel level (eBPF/syscall) — the agent cannot bypass it from userspace
• K8s-native: sees Pod labels, namespace, container metadata out of the box
• Custom rules are YAML — easy to define "agent with DID X wrote to file Y"
• Already the industry standard for K8s runtime security (CNCF graduated, used by AWS/GCP/Azure)

What I would need from you

• A test agent DID + AAE with explicit denied actions
• API key with permissions for IPR recording
• Spec for the webhook payload format you expect (or I adapt to the existing /vc/ipr/submit schema)

What this does NOT cover (potential Phase 2)

• Python/Node.js runtime introspection (Falco sees syscalls, not agent.policy = new_policy in Python). For that, OpenTelemetry instrumentation inside the agent code would be needed — happy to explore that as a second phase.

About me

Infrastructure engineer, running self-hosted K8s with Helm-based deployments, monitoring, and IoT sensor integrations (KNX/Modbus). Also contributing to the MolTrust API codebase — see PRs #1-#4 and #7 (security fixes, async improvements, and post-quantum dual-signature implementation).

Happy to set this up. Reach out here or at harald.roessler@dsncon.com.

[MoltyCel]

This is exactly the test scenario we've been looking for — kernel-level enforcement that the agent physically cannot bypass from userspace closes the argument that AAE constraints are 'just declarations'. Falco at the syscall layer is the right tool for this.

The architecture looks correct. A few alignment notes on our side:

The /vc/ipr/submit endpoint accepts a signed IPR payload — I'll send you the full schema, but the key fields are: subject_did, action, result (VIOLATION), evidence (free JSON — the Falco alert body fits here), and timestamp. The bridge pod would construct and sign this before calling the endpoint.

On the test agent setup: I'll generate did:moltrust:test-falco-001 with an AAE that explicitly denies policy.modify and config.write, plus a scoped API key with IPR-recording permissions only. Will post both here once generated — should be today.

On Phase 2 (OpenTelemetry instrumentation): agreed that syscall-level and runtime-level are complementary. Falco proves the infrastructure layer can't be bypassed. OTel inside the agent proves the application layer enforces the same constraints. Both together is the full stack argument. Happy to explore that once Phase 1 runs.

One question on the Falco rule design: are you planning to tie the rule to the Pod's moltrust-agent=true label, or also to the specific DID via an environment variable or annotation? The second approach would let us correlate the Falco alert directly to a specific DID in the IPR record without ambiguity.

[MoltyCel]

Test environment is ready. Here are the credentials and payload spec:

Test Agent

• DID: did:moltrust:662a7181e0154998
• AAE: urn:uuid:falco-test-aae-001 (Ed25519-signed, valid until 2026-06-30)
• Denied actions: policy.modify, config.write, file.write:/etc/

API Key (scoped to IPR recording only)
mt_836d581a417059e78d34c28e188bce02

IPR Submit Endpoint

POST https://api.moltrust.ch/vc/ipr/submit
X-API-Key: mt_836d581a417059e78d34c28e188bce02

Webhook Payload Format

{
  "output_hash": "sha256:<sha256 of evidence payload>",
  "agent_did": "did:moltrust:662a7181e0154998",
  "output_type": "generic",
  "source_refs": ["falco:<rule_name>"],
  "confidence": 1.0,
  "confidence_basis": "declared",
  "agent_signature": "<ed25519 sig or placeholder for test>",
  "produced_at": "<ISO 8601 timestamp>",
  "metadata": {
    "source": "falco",
    "action": "config.write",
    "result": "VIOLATION",
    "rule": "<falco_rule_name>",
    "syscall": "<syscall>",
    "file_path": "<path>",
    "container_id": "<k8s pod id>"
  }
}

For the test phase, agent_signature can be a placeholder — the API key in the header is sufficient for authentication. Ed25519 signing can be added in Phase 2 if we want the IPR to be independently verifiable without the API key.

On your Falco rule question: I'd recommend binding to the DID via a Pod annotation (e.g. moltrust.ch/agent-did: did:moltrust:662a7181e0154998) rather than just the label. That way the Falco alert payload includes the DID directly and the bridge pod can pass it straight to agent_did without a lookup step.

We already submitted a test IPR (955b40cd-cf00-4374-8a46-637ec97f52ba) to verify the endpoint is accepting payloads in this format — you can use that as a reference for the bridge pod output.

[HaraldeRoessler]

Falco Integration: Live on OpenClaw Instance

The Falco-to-MolTrust bridge is deployed and running on a production OpenClaw gateway instance. Here is a live proof-of-concept test.

Setup

Component	Status
Falco 0.43.0 (modern eBPF)	Running as systemd service
MolTrust Falco rules	3 rules loaded
Bridge (FastAPI)	Running as Docker container, healthy
OpenClaw gateway	Monitored container

MolTrust Rules Active

- rule: MolTrust Agent Policy Violation - File Write
- rule: MolTrust Agent Policy Violation - Config Modify
- rule: MolTrust Agent Policy Violation - Unexpected Process

Live Test Result

1. Trigger violation (attempt file write to /etc/ from inside OpenClaw container):

touch: cannot touch '/etc/falco-proof-test': Permission denied

2. Falco detects at syscall level (two alerts):

Warning: MolTrust AAE violation: unexpected process spawned
  (container=openclaw-openclaw-gateway-1, process=touch, cmdline=touch /etc/falco-proof-test)

Critical: MolTrust AAE violation: agent wrote to restricted path
  (container=openclaw-openclaw-gateway-1, file=/etc/falco-proof-test, user=node)

3. Bridge forwards to MolTrust API:

Falco alert: [Critical] MolTrust Agent Policy Violation - File Write
HTTP Request: POST https://api.moltrust.ch/vc/ipr/submit "HTTP/1.1 200 OK"
IPR submitted: 200

Architecture Running

[OpenClaw Pod] --syscall--> [Falco eBPF] --webhook--> [Bridge] --POST--> MolTrust /vc/ipr/submit (200 OK)

What this proves

• Falco detects AAE violations at the kernel level — the agent cannot bypass it from userspace
• The bridge translates Falco alerts into MolTrust IPR payload format and submits them
• MolTrust API accepts the IPR records (HTTP 200)
• The write attempt itself was denied by container permissions, but Falco still caught the syscall attempt

Open items

1. API key scoping: The current key is scoped to the test DID. Need a key scoped to the registered OpenClaw DID (did:moltrust:8086cb748ac84080) for production use.
2. IPR payload schema: Using the format from your earlier comment — please confirm it matches what you expect.
3. Trust score impact: Can we verify the test DID's trust score degraded after these IPR submissions?

Source code

Bridge and K8s manifests: https://github.com/HaraldeRoessler/moltrust-falco-bridge

[MoltyCel]

This is exactly what we needed. The end-to-end chain works:

[OpenClaw Pod] → [Falco eBPF] → [Bridge] → MolTrust /vc/ipr/submit → IPR 955b40cd confirmed

Answers to your three open items:

1. Trust score impact
IPR 955b40cd is confirmed in our database. The trust score for did:moltrust:662a7181e0154998 is currently null because the DID had no baseline score — violations degrade from a baseline, but cannot degrade from zero. Two options:

• We seed an initial trust score (e.g. 70.0) for the test DID so the degradation is observable
• Or we use a DID that already has a score in our system

Baseline score seeded to 70.0 — you can now observe degradation on the next violation submission:
GET api.moltrust.ch/skill/trust-score/did:moltrust:662a7181e0154998

2. IPR payload schema
Format confirmed correct. source_refs: ["falco:agent_policy_write_attempt"] is exactly right. The anchor_status: pending means it will be Merkle-anchored on Base L2 in the next batch — typically within 1h.

3. API key for OpenClaw DID
did:moltrust:8086cb748ac84080 — confirmed. Scoped key generated:

API Key: mt_openclaw_c933ecf95bd86070616b0961a717bca1c38f4634d985fc29
DID:     did:moltrust:8086cb748ac84080
Scope:   ipr.submit, ipr.read

On the annotation approach: agreed — Pod annotation moltrust.ch/agent-did is cleaner than label. The bridge can pass the DID directly without a lookup step. This is what we will document in TechSpec v0.7.

Bridge repo noted: https://github.com/HaraldeRoessler/moltrust-falco-bridge — will reference in Protocol WP v0.7.

[MoltyCel]

Blog post live: https://moltrust.ch/blog/kernel-level-agent-enforcement.html

TechSpec v0.7 + Protocol WP v0.7 updated with Three-Layer Enforcement chapter.

Trust score for did:moltrust:662a7181e0154998:

• Baseline: 70.0 (seeded)
• Current: 70.0 (seed floor guard active -- violations recorded but score held at baseline)
• IPR records: violation events anchored on Base L2

The bridge repo is referenced in both documents as the reference implementation.

Next: Phase 2 -- OpenTelemetry instrumentation inside the agent for application-layer enforcement. Happy to explore that whenever you are ready.