Check more than the sender
Verify where each input came from, then check its content. Authentication alone is not enough.
Open-source infrastructure checks
What if the instruction
is wrong?
Infrastructure tools follow instructions. Telosieve checks whether those instructions make sense: it compares the requested change with observed state and rules for what must stay safe. If the checks disagree, it reports a refusal instead of recommending a change.
Today: a read-only evaluation tool. It writes reports, not changes to your infrastructure. It does not automatically stop other tools from acting.
Why another check?
The right sender can still send the wrong instruction.
Suppose an automated tool is told to remove a configuration value that your rules say must stay present. The instruction is signed, but it is still wrong. Telosieve checks the request against the observed configuration and those rules, then reports a refusal. A valid signature identifies the signing key; it does not make the requested change safe.
Say when there is no answer
Missing or conflicting evidence produces a refusal report you can inspect, not a guessed recommendation.
Keep each check limited
Set limits on input size, supported cases, and execution time. Exceeding a limit produces a refusal.
How it works
Compare the request. Test what could be wrong.
Give Telosieve three separate inputs: the requested change, observations from multiple collectors, and rules for what must remain true. You also specify which sources could be faulty. Telosieve tests those cases, leaving out the suspect source in each case, and checks each proposed result with a separate checker. Every tested case must support the same safe result. If even one case has no safe result, or the results disagree, Telosieve refuses.
Swipe or use the arrow keys to explore the full architecture
Supported integrations
Try it with the systems you use.
These integrations collect evidence without changing the target system. Multiple authenticated collectors must agree on the exact data used in an evaluation. Each guide explains setup, tests, and limitations.
K8S↗
TOFU↗
RDS↗
PG↗
HTTP↗
V1↗
Kubernetes
Evaluate exported cluster snapshots or collect live state through read-only API calls.
OpenTofu
Evaluate saved plans without backend credentials or running apply.
Redis
Read a selected set of keys using accounts that cannot write to Redis.
PostgreSQL
Read a consistent database snapshot using roles restricted to SELECT.
HTTP/JSON
Collect JSON snapshots using authenticated GET requests. No write requests are sent.
Your system
Build another read-only integration using the documented adapter interface.
Testing and limitations
You can inspect failures as well as successes.
The test suite includes malicious instructions, conflicting observations, stale data, and timeouts. Reports retain the evidence behind refusals. These are tests run by the project, not an independent security assessment. If several sources fail together in a way the configured checks do not cover, Telosieve may not detect it.
Explore adversarial coverage- 3
- inputs: request, observations, rules
- 2
- local examples to get started
- 0
- changes to target systems
- 1
- agreed result required, or refusal
Before you rely on it
- This is evaluation software, not a production safety guarantee.
- It does not apply changes to production systems.
- Several collectors may still share an administrator or failure cause.
- It cannot cover every attack or an incorrect safety rule.
- Independent security assessment is still needed.
- Legal clearance of the name and mark is separate.
Start with two examples
See a result. See a refusal.
The local quickstart runs a benign request and a poisoned instruction. Compare their reports, then explore the integration guides or assess the checks yourself. Telosieve is written in Rust and released under Apache-2.0.