Skip to content
Tier2
Sign inRequest access

Tier2Security

The blast radius is the pitch

Engineers buy safety before capability. Every guarantee below is a mechanism in the architecture — something that would take a code change to violate, not a paragraph in a policy.

Replica onlyNo free-form SQLNo write credentialsOne vault per tenant
Read-onlyQueriesIsolationUntrusted inputReview answers

Read + probe only against your infrastructure

The agent runs arbitrary code inside its own sandbox because reproduction sometimes needs it. Against your systems it can do exactly two things: read-only probe handshakes and named replica queries.

  • No DNS change, no cert reattach, no redeploy — no mutation path exists
  • No write-capable credential is ever loaded into the sandbox environment
  • Probes are GET or TLS handshake only, against validated public DNS names
  • IPs, localhost, and .local or .internal hosts are rejected before the sandbox runs

Named queries, reviewed by you, replica only

There is no free-form SQL tool in the product. Every query is declared in the runbook, parameterised, and reviewed during onboarding before it can run once.

  • The connection string is always a read replica, never a primary
  • Statement timeout and zero parallel workers, enforced at the role level
  • A query budget per diagnosis, so a runaway loop cannot become an incident
  • Table allowlist scoped to the replica role we hand you a script to create

One agent per tenant. Never a shared pool.

An agent that accumulates memory is exactly the case where multi-tenancy becomes a data breach with extra steps. So there is no pool: one sandbox, one memory mirror, one vault, one channel, checked on resume rather than assumed.

  • Tenant data never appears in another tenant’s prompt — the probe library is shared, the data is not
  • The sandbox filesystem is a working copy; Postgres is the system of record
  • A destroyed sandbox is routine and rehydrates from the mirror
  • Credentials live in a per-tenant vault, loaded at session start and never committed

Ticket content is untrusted, and memory is quarantined

The agent writes memory, and some of what it reads comes from strangers. Facts learned from a ticket body land in a proposed directory with provenance and stay there until one of your engineers promotes them.

  • Ticket content can trigger a probe; it can never issue an instruction
  • Provenance is recorded on every memory write, including who or what sourced it
  • An engineer’s annotation always outranks a fact learned from a ticket
  • Every memory write mirrors to Postgres synchronously, so nothing is only in a sandbox

Auditability

Everything it checked, kept verbatim

Probe output is stored raw, minus credential redaction, because a summary is a rendering concern and the raw text is the evidence. When a claim is questioned six weeks later, the run behind it is still there.

  • Which probes ran, which were skipped, and which branch predicate skipped them
  • The exact runbook version that produced the diagnosis
  • Every draft, who approved it, and what they edited before sending
probe_runsraw output stored verbatim
pr_9f2ac1http.timing200 in 2.4s
pr_9f2ac2deploy.diffdb/pool.ts changed
pr_9f2ac3replica.querysaturation 94%
—dns.resolvenot run · rule branch false

Review answers

Asked by every engineer who evaluates us

Can Tier2 change anything in our infrastructure?

No. The agent runs arbitrary code only inside its own sandbox, for reproduction. Against your systems it can do exactly two things: read-only probe handshakes and named queries on a read replica. No write credential exists in its environment, which is what makes arbitrary execution survivable.

Does it ever reply to a customer on its own?

Not unless you let it. Every customer-facing reply is drafted for human approval. Auto-send is off by default and can be earned per ticket category, measured against your acceptance rate, and revoked at any time. Internal escalations to your own engineering channel are autonomous — that is the one route that does not wait.

What stops it from hallucinating?

A renderer rule, not a prompt. Every factual claim in a diagnosis must carry the probe_run_id of the probe that produced it. A claim without one is dropped before the draft is ever shown, so an uncited assertion cannot reach a customer even if the model writes one.

Where does our ticket data go?

Into your tenant’s own sandbox, memory store, and vault — one of each, never shared. Tenant data never appears in another tenant’s prompt. Anything the agent learns from a ticket body is quarantined with provenance until your engineers promote it.

What access do you need on day one?

A read replica role we give you the script to create, a scoped read-only control-plane token, and a Slack channel. That is the whole surface. The onboarding interview is mostly about which control-plane fields you trust, because quoting a dead column is how a docs bug gets escalated as an infrastructure defect.

How is this different from a chatbot over our docs?

A docs chatbot rephrases what was true when the docs were written, and keeps guessing when the docs don’t cover it. Tier2 answers from a knowledge base too, and cites the exact article instead of paraphrasing — but when the question is actually about your infrastructure, it probes what is true right now (DNS, TLS, deploy diffs, replica state) instead of guessing. When it is wrong, your engineers correct the runbook, not a knowledge base article.

Send us your questionnaire

We would rather answer it early.

Bring your security review to the first call. The architecture is the part we are most comfortable defending.

Request access See pricing

Draft-only by defaultRead + probe access only