Trust at the Edge: Security, Federation, and Backpressure

Ruflo’s security question is not simply whether an agent is “safe.” It is what may cross each boundary, who is allowed to authorize it, and what happens when a tool, peer, or budget behaves badly. This chapter follows Ruflo from local policy and storage controls into federation: discovery, attestation, PII handling, signed messages, cost limits, breaker states, and optional network isolation. The practical judgment is which safeguards actually enforce a boundary and where an operator still needs an independent check.

Security is a stack of different authorities

The word security hides several distinct jobs. A policy engine decides whether an identity may request an action under a set of rules. A budget decides whether the action can consume more tokens or money. An approval may authorize a narrowly scoped exception. A receipt records what decision was made and links it to prior decisions. A threat scanner looks for suspicious content. Encryption protects stored bytes if someone obtains the disk or a backup. These controls complement one another; none can stand in for all the others.

Ruflo’s product-plane policy code makes this separation explicit. A request carries an identity, an audience, a tenant, an action, resource references, and an authoritative source. Validation rejects unknown fields, malformed identifiers, wrong authorities, tenant mismatches, invalid timestamps, missing action obligations, and unsupported privacy classes. Signature verification is necessary, but it is followed by audience and tenant checks, freshness and expiry checks, local policy, capability verification, and an atomic replay reservation. A valid signature does not turn an arbitrary request into an allowed operation.

The policy engine also distinguishes observation from enforcement. Ruflo can run in a legacy-compatible mode, an observe mode, or an enforce mode. In an observe posture, a decision can be recorded while the requested action remains allowed for compatibility. In an enforce posture, a denied policy or exceeded budget becomes a denied outcome. This distinction matters when reading dashboards: a recorded policy decision is not necessarily a blocked action.

Approvals add authority without making it unlimited. The implementation refuses self-approval, checks the issuer when a verifier is configured, requires expiry and a positive maximum-use count, and consumes an approval when it is used. The resulting receipt contains a hash chain and can optionally carry a signature. Such a ledger makes policy decisions auditable and tamper-evident. It does not prove that the rule itself was wise, that the identity was benevolent, or that a downstream side effect succeeded.

AIDefence covers a different boundary. The built-in engine detects patterns associated with prompt injection, system-prompt extraction, jailbreak language, data exfiltration, and several forms of PII. It returns a threat decision, confidence, a hash of the input, and timing information. The plugin guidance describes a three-gate pattern: screen PII before storage, sanitize or vault sensitive blobs, and check extracted text before it re-enters a model prompt. These are useful choke points because untrusted text can become dangerous at storage, prompt construction, or execution—not only at the moment it first arrives.

Pattern detection is not semantic understanding. A regular expression can miss a novel attack, overflag an innocent phrase, or identify a credential-shaped string that is not actually a credential. The system can improve calibration, but no scanner result should be treated as a complete security review. Likewise, a policy response is only protective when the caller places the response on the path that performs the action.

That last point is important for Ruflo’s marketplace hooks.