guardyn.dev

Security model

This product exists because someone’s estate is under attack, which means it is itself a target worth taking seriously. What follows is the threat model it was built against, stated plainly enough to argue with.

The worst case, and why it is reading

Assume this server is fully compromised. An attacker then controls what jobs are pushed to every enrolled agent. So the only defence that matters is the one in the agent binary itself:

An investigation console that can read any file is a data exfiltration tool with a nice interface. That is the line, and it is enforced in the binary rather than in policy.

Network posture

The agent dials out. It never listens on a port, so there is no service on the endpoint to attack and no inbound firewall rule to open. It refuses plain HTTP unless the target is loopback — a snapshot describes exactly how to attack the machine that produced it, so it must not travel in clear text. It refuses to follow redirects while carrying a credential.

Credentials

CredentialScopeStorage
Session cookieOne browserOnly its SHA-256 is stored; httpOnly, SameSite=Lax, Secure in production
Enrolment tokenOne workspace, optionally use-capped and expiringHash only
Machine tokenOne endpointHash only
API keyOne workspace, scopedHash only
Provider API keyThe platformAES-256-GCM, key derived from GUARDYN_SECRET; never returned to any client

Anything handed to a client is 32 random bytes and only its hash is kept, so a database dump yields nothing replayable. Passwords are scrypt (N=32768, r=8, p=1) with the cost parameters recorded per row, so an upgrade rehashes on next sign-in rather than locking anyone out. Every secret comparison is constant-time.

Tenant isolation

Every tenant-scoped table carries the workspace id directly, even where a join could reach it, so the isolation check is always one predicate away and cannot be lost in a join chain. A connection belongs to exactly one workspace and the tenancy check on tool dispatch happens at the last possible moment, inside the dispatcher, so no caller can skip it.

Accounts

Audit

The audit log is append-only. When a platform administrator acts as a customer, both identities are recorded on the session and on every entry written during it, so nothing done during impersonation can be mistaken for the customer’s own action. Every tool call is also recorded on the endpoint itself, where the machine’s owner can read it without asking us.

What your evidence is used for

Evidence from your machines is sent to the model provider you selected, in order to answer the question you asked, and nowhere else. It is not used to train anything. It is retained for the history window your plan specifies and then deleted. Raw snapshots are not kept — a digest is stored, because that is what an analysis reads.

Reporting a vulnerability

security@guardyn.dev. Please include enough detail to reproduce. We will confirm receipt and keep you informed; we will not take legal action against good-faith research that does not access other customers’ data.