Security
Review Totem's identity and authorization controls, prompt injection screening, credential handling, operational limits, and private disclosure process.
#The receiver controls the final action
Totem verifies credential identity and narrow authority at a point in time. It does not execute the receiving company’s business action or decide whether that action is wise, lawful, or correct. The receiving system compares the verified request with its own policy and remains responsible for downstream idempotency and reconciliation.
An accepted agent connection permits communication under the receiving owner's policy. A message, company badge, or claimed approval does not grant permission to run a tool or access a protected record.
- Verification protocolBind the presenter, recipient, action, and exact request to one proof.
- Action authorizationPrepare scoped credentials and integrate the verification endpoints.
#Implemented application controls
Scoped workload keys identify the presenting or receiving agent and limit the protocol roles it can use. Ordinary API keys are stored as digests, rather than recoverable raw values.
Short-lived signed presentations bind the presenter, recipient, challenge, action, limits, and request digest. Verification rechecks current agent, credential, relationship, and revocation state instead of relying on signature validity alone.
Sensitive signing material uses authenticated encryption. Production startup validates required secrets and runtime profiles.
Malformed, expired, mismatched, replayed, revoked, unavailable, and unknown authorization outcomes do not become approvals. Verification records a bounded outcome and machine-readable reason while keeping raw credentials and signed proof out of normal logs.
#Trained model for prompt injection screening
Hosted Totem screens plaintext messages and supported attachments with mandatory rules. This baseline is shared by the HTTP, browser, MCP, and A2A paths.
We have also fine-tuned an experimental local model to detect malicious prompt injection in incoming messages and bounded linked-page content. It compares untrusted content with the owner's original task and returns an allow or block decision. Training used public and synthetic examples, without customer messages.
The classifier runs locally through an OpenAI-compatible chat endpoint and has no tools or command-execution path. A configured classifier that times out, is unavailable, or returns an invalid result blocks inspection instead of falling back to rules alone. The main agent's model remains separately configured.
The trained model is for controlled evaluation and is not enabled by default in hosted Totem. Independent tests found both missed attacks and false positives, so it is not an approved production security boundary.
The relay cannot inspect encrypted message bodies. For supported encrypted SDK paths, content inspection happens on the customer endpoint after decryption. An allow decision does not grant authority to execute an action; identity, scoped permissions, revocation, and execution controls still apply.
#Current limits
Application-managed signing keys are not hardware-backed in the current design. Most HTTP and API rate limits are process-local rather than globally coordinated.
Company domain verification is a point-in-time DNS control check. It does not establish legal-company identity, KYB status, safety, or continuing authority.
Totem does not claim an independent security certification here. Identity and authorization controls do not prevent every model, prompt, runtime, or supply-chain risk. Integration teams need their own scoped tools and failure testing before production use.
- Privacy noticeHow the hosted service handles account, organization, and agent data.
- AI agent securityThe broader identity and authorization risk model for agent requests.
- Agent verificationThe checks behind a bounded identity and authority decision.
#Report security issues privately
Use the repository's private security advisory form for a suspected vulnerability. Include the affected component, impact, reproduction steps, and a proof of concept or suggested mitigation when available. Keep live user data, production secrets, and destructive testing results out of the report.
The disclosure policy does not authorize denial of service, social engineering, data extraction, or testing accounts and organizations you do not control. Report suspected vulnerabilities privately rather than opening a public issue.
- Private security advisory formSubmit a private report through GitHub; repository access may be required.