Security Model

This page is the technical counterpart of Security & Trust .

Tenant Isolation, Three Layers  

Three mechanisms keep each organization’s data apart, and each has limits worth knowing:

1. Your perimeter: the agent runs inside your network and, with its default local connectors, reads and loads your records there. It sends the control plane metadata, run results, and advisor statistics, and receives connection credentials and commands from it; Security & Trust lists each of these.
2. Database row-level security: row-level security scopes each tenant table to the request’s tenant, so a query on the application’s connection sees that tenant’s data. Two exceptions are deliberate: a person can see their own memberships and organizations, and an invite can be looked up by its token. Row-level security does not enforce roles; the policy engine does. Some platform reads and writes use a connection that row-level security does not restrict, among them storing the run events agents send, agent registration, the scheduler, and the command queue; there the code, not row-level security, keeps tenants apart.
3. Per-organization vault projects: each organization’s secrets live in a project of its own in Amfelt’s Infisical vault, which the control plane reaches through a machine identity scoped to that project. One encryption key, for the whole vault, protects every project.

Secrets  

Agents do not talk to the vault: an agent refuses to start when a vault address is set on its host. For each job, discovery, advise run, or connection test, the agent asks the control plane for the connection, and the answer includes the password. Connection details entered in the web app, and a login given to amfelt add-target --user or --password, are stored in the organization’s vault project; --store-login-in-file keeps the login in the project file on the host instead. The control plane stores each vault project’s machine-identity secret encrypted with AES-256-GCM.

Authentication  

People sign in through Hanko, a managed authentication provider, and the API verifies the token Hanko signs on every request a signed-in person makes. A registered agent authenticates with tokens it signs with its own Ed25519 key, one per connection or request. A token is valid for five minutes by default; amfelt channel --token-ttl sets the lifetime of the channel’s token, and the control plane requires an expiry but sets no maximum.

Authorization  

Routes that need a permission are checked by a policy engine that denies by default: an unknown user, an unknown role, or a role without the permission is refused. Many reads need only membership of the organization. Four roles are enforced (owner, admin, operator, viewer), and row-level security, described above, scopes queries by tenant, not by role.

Audit  

The permission checks that guard routes log each decision, allowed or denied, with the actor, organization, route, outcome, and reason. Reads and changes of projects, environments, data platforms, sources, jobs, and contracts, schedule pauses and resumes, and reruns are also written to an append-only audit table. A few checks inside handlers, such as the guard on changing an owner’s membership, write no audit event of their own.