TIENDocumentation
Docs/Safety

Security model

Tien reduces the time between generated code and a reviewable security baseline. It does not declare an application secure, exploit vulnerabilities, or replace threat modeling, architecture review, penetration testing, or incident response.

Local-first repository analysis

Tien coordinates local commands or explicitly configured Docker images. It does not require source code to be uploaded to a Tien service.

Some underlying engines may access the network to download images, rules, or advisory databases. Review each engine's behavior and pin versions in controlled environments.

URL safety budgets

Current built-in URL checks use a controlled request profile:

  • only GET and HEAD requests;
  • no credential guessing or brute force;
  • no injection payloads, fuzzing, or exploit attempts;
  • no aggressive crawling or wordlists;
  • configurable redirects, response bodies, retries, concurrency, and per-target time;
  • redirects that change scheme, hostname, or effective port are blocked.

These budgets protect runtime resources. They do not impose a fixed ceiling on targets, findings, or repository file coverage.

The output is evidence about observable configuration. It is not proof that a vulnerability is exploitable.

These guarantees apply to Tien's built-in checks. External plugins are operator-trusted processes and are not network-sandboxed by Tien; they must enforce equivalent read-only behavior and egress policy themselves. When a plugin is enabled, MCP marks the corresponding scan tool as potentially destructive instead of advertising a non-destructive guarantee.

Authorization before execution

Scan only code and systems you own or are explicitly authorized to assess. Every public URL target requires a structured DNS TXT authorization containing an exact hostname, the url-scan function scope, an exactly 256-bit challenge, and issue and expiry timestamps.

The url-scan scope authorizes only the current built-in GET/HEAD checks. Authorization is fail-closed and all-or-nothing: no worker, cache lookup, or built-in request starts until the complete target list passes. If the earliest grant expires during execution, Tien aborts the run with authorization failure; MCP returns a tool error, not partial success. A batch containing a public target fails closed when a URL plugin is enabled. URL plugins can currently run only against explicitly proof-exempt literal localhost or private-IP development targets; a future public or active plugin needs its own origin-bound signed capability and must not reuse url-scan.

DNS TXT proof is a cooperative operational signal, not legal or contractual authorization. It does not replace written permission or rules of engagement, and a modified binary or fork can remove the check.

The MCP server loads operator-owned configuration fields once at startup, and an agent tool call cannot replace engines, plugins, arguments, or URL authorization. An explicitly selected missing, unreadable, or invalid --config path fails startup instead of falling back to defaults. This is not a complete execution snapshot: referenced rules, executable binaries, ignore files, advisory data, and mutable image tags can change independently. Keep those resources outside agent-writable roots where practical, protect their permissions, and pin versions or digests.

Localhost and literal private IPs are blocked by default, with explicit development exemptions. A hostname that resolves to an RFC 1918 or IPv6 ULA private network must appear exactly in the operator-owned allow_resolved_private_hosts allowlist, use an HTTPS target, and present its exact DNS TXT grant. The resolved addresses are pinned during authorization preflight and reused for the scan. The allowlist does not permit wildcards, loopback, link-local, CGNAT, multicast, unspecified, or metadata addresses. Treat shared staging environments as real scoped systems.

Evidence and secrets

Secret evidence is redacted by default. Keep this setting enabled:

output:
  redact_secrets_in_evidence: true

Reports may still contain sensitive file paths, package versions, URLs, header values, or architecture clues. Store scan artifacts with the same care as source code and operational logs.

Interpreting findings

Every finding has severity and confidence, but neither replaces context.

  • Verify the target and evidence.
  • Determine whether the code is reachable or the URL is exposed.
  • Check for compensating controls.
  • Prefer fixing a root cause that resolves several findings.
  • Rerun the relevant tests and Tien after the change.

False positives should be documented. Do not weaken the global ruleset or hide whole folders without understanding the tradeoff.

Trust boundaries

Tien itself, external scanners, Docker images, custom plugins, CI runners, and AI agents are separate trust boundaries.

  • Pin executable, ruleset, advisory-data, and image versions or digests.
  • Review plugin code and give it the least access it needs.
  • Avoid passing secrets in command-line arguments.
  • Keep agent scope explicit and prevent agents from scanning inferred third-party targets.
  • Treat generated remediation as a proposal that still needs code review and tests.

Responsible use

Tien is for defensive review of authorized systems. If you need active testing, use a purpose-built tool under a documented engagement scope.

Report vulnerabilities in Tien privately through GitHub Security Advisories rather than a public issue.