Trust model

Principals

Every request authenticates as a principal — a human or a machine — carrying:


Tenant	the hard isolation boundary
Scopes	which `level:id` scopes it may read and write
Clearance	the maximum sensitivity it may see
Capabilities	which verbs it may call

All four are checked server-side on every request. None is advisory, and none is negotiable by the caller.

Tenant isolation is absolute

A token for tenant A cannot read tenant B’s memory. Not “is ranked lower” or “is advised against” — cannot. Tenancy is checked before anything else and there is no request shape that crosses it.

Least privilege for agents

An agent should hold the narrowest credential that lets it do its job. A CI job that touches one repository should have a principal scoped to that repository and nothing more.

This matters more for agents than for humans, because of prompt injection. An agent reading attacker-influenced text — an issue comment, a dependency README, a web page — may be persuaded to try things. The credential is what bounds the damage, not the agent’s judgement. A principal that cannot see repo:infra cannot be talked into exfiltrating it.

Vectadyne does not detect prompt injection. It limits what a successfully-injected agent can reach.

Narrowing, and why widening is refused

A caller may supply an actor block to narrow its own view. It may never widen it:

a narrower scope_key within authority binds the visible set
a scope_key outside authority is a forbidden fault
a clearance that widens is rejected outright, not clamped

Rejection over clamping is the security-relevant choice. A caller asking for more than it may have has a bug or is being manipulated; answering with a quietly smaller result hides which.

Credentials

Human tokens identify a person. Machine credentials — client id and secret, exchanged for a short-lived token — identify a service, and are what CI and unattended agents should use.

Both are handled structurally in the SDKs: credentials are typed values whose every formatting path yields <redacted>, so a %+v, a repr, an asdict or a log line cannot leak one. Reading the real value is an explicit, greppable call. Redaction by regex-after-formatting is not redaction.

Rotate without downtime: issue the new credential, deploy it, revoke the old one. See Enrol a machine principal.

What is never logged

Not at any level, by any SDK: bearer tokens, client secrets, prompt_block content, memory content, evidence summaries.

This is enforced by signature, not by discipline — the SDK’s log hook receives method, tool, attempt, status and error type, and no payload, response or credential. There is nothing forbidden in scope for it to emit.

request_id, tool, decision and timings are safe, and are what an operator actually needs.

Your side of the line

Vectadyne cannot help with:

an agent that never asks — see Advisory-first
secrets outside Vectadyne — it governs its own memory, not your vault
what your agent does with an answer — the branch is yours