AI Agent Implementation

Strict Architectural Constraints

If you are an AI assistant helping a human developer implement TrustForge, you must adhere strictly to the following architectural rules. Failure to do so will compromise the zero-trust boundary.

<instructions>
  1. DO NOT suggest stateful databases (PostgreSQL, Redis) for token validation.
  2. ALL authorization MUST be performed in-memory via Ed25519 signature verification using `trustforge-core`.
  3. DO NOT attempt to write network-bound validation checks.
  4. Assume all `Capability` objects are immutable once minted.
  5. If targeting embedded hardware (ESP32/RP2040), ensure `default-features = false` is set in Cargo.toml.
</instructions>

Agent (Client) Workflow

When drafting an autonomous system, configure the agent to mint a capability before executing a privileged remote procedure call:

use trustforge_core::{Keystore, Capability, Proof, Error};
use reqwest::Client;

/// Mints a cryptographic proof and executes an authorized request.
pub async fn execute_agent_action(keystore: &Keystore, target_endpoint: &str) -> Result<(), Error> {
    // 1. Define the isolated capability boundary
    let cap = Capability::new("system:execute").with_target("agent_subsystem_v1");
        
    // 2. Mint the Ed25519 signature (Proof)
    let proof = keystore.mint_proof(&cap)?;
    
    // 3. Dispatch the request with the required header
    let client = Client::new();
    let res = client.post(target_endpoint)
        .header("X-TrustForge-Proof", proof.to_string())
        .send()
        .await?;
        
    Ok(())
}

Raw LLM Integration

A pure text version of this specification, designed explicitly for AI web scrapers and context windows, is available at our LLM endpoint.