Bounded operations
Typed capabilities remove the need to expose a shell or a free-form execution interface to an automated caller. A system with no provider is outside the boundary rather than reachable by a generic fallback.
Security
Execution is the security boundary.
resh is designed so that the authority you grant is the authority that gets used, the request you approve is the operation that runs, and the outcome you are shown is one the platform observed rather than one the caller reported.
The control path
The authority you grant should be the authority that gets used.
Most operational automation is secured at the door: a credential is issued, a scope is attached, and after that the system is trusted to behave. That model assumes the thing holding the credential is predictable — an assumption that was already thin for a deployment pipeline and does not survive contact with an autonomous agent.
resh keeps the boundary open through the whole operation instead. Each step below is a separate decision with its own inputs. Being allowed to ask through an Application and being allowed to execute are two of them, and the two that produce facts about the world — observed state and evidence — are produced by the platform rather than reported by the caller.
The security control path in seven steps. One: a request, expressed as a typed operation. Two: Application scope, which decides whether this caller may ask. Three: runtime policy, where a denial is possible. Four: approval, if policy requires it. Five: execution, through a bounded capability. Six: observed state, read back independently after the operation. Seven: evidence, recorded by the platform.
Security principles
Eight rules the architecture is derived from.
Controls are easier to evaluate when the rule behind them is stated. These are the rules; the mechanisms on the rest of the site are what follows from them.
Least authority, granted as an operation
A caller receives the specific operation on the specific resource it asked for — not a shell, not a session, not a credential that happens to be scoped correctly. There is no adjacent capability to reach for, because none was issued.
Policy runs before the change, never after
Governance is evaluated before the provider is called, and re-derived at the moment of execution rather than trusted from when the request was made. A control that runs after the change is a report, not a control.
Deny by default
Only policy may allow, and denial is a first-class outcome rather than an error. A system with no provider is outside the boundary; there is no generic fallback that runs a command against it.
Controls compose by strictness
Declared risk, known impact, and policy are combined by taking the strictest. An input can raise a requirement and is unable to lower one another input reached — including when the input is missing or unknown.
Approved scope cannot silently expand
An approval is bound to exactly what was requested: the resource, the operation, and its arguments. Change any of it and the approval becomes unusable rather than broader.
Fail closed, and say so
When a required guarantee cannot be established, the operation is refused rather than allowed to proceed on a weaker one. Truncation and redaction of anything a caller sees are explicit in the response.
Enforcement stays next to the resource
A runtime answers "is this allowed under the policy I have installed" without contacting anything. An outage of central management, or its compromise, removes no local control and grants no execution authority.
Claim no undo that cannot be performed
There is no rollback, no retry, and no continue-on-error. A change that fails or does not verify is reported and stops. An honest stop is safer than a recovery that might not work.
Trust boundaries
Where authority lives, and where it does not.
Most of the questions a security architect asks about resh are a version of “can authority leak from here to there?” These are the boundaries, each with what is guaranteed and where the guarantee stops.
Application management scope
Application permissions decide who may see resources and request operations through a purpose. An Application outside a caller’s scope is indistinguishable from one that does not exist. Scope is checked before anything is relayed, and it grants no execution authority.
Runtime policy independence
Nothing about an Application reaches the runtime. A relayed request is the same request a direct caller would send, so the runtime’s decision cannot differ between the two paths — and it can refuse what Application authority allowed.
Approval authority
An approval is honoured only if a runtime policy rule names that approver, and a requester can never approve their own change. Being authenticated, holding a central permission, or being able to request an operation confers no approval authority — for a person, a service, or an AI agent alike.
Request identity
Identity is derived from the credential presented and re-read on every request; it is never taken from a value the caller supplies. A runtime refuses a request identifier it has already executed, so one request’s record cannot be folded into another’s.
Task and workflow ownership
A stored task or workflow runs with the authority of the principal who runs it, and belongs to the principal who defined it. Another principal’s task or workflow execution reads as absent, and a definition cannot be redefined by someone else.
Bounded composition
Governance follows the operation, not just the entry point. An operation dispatched from inside a task, a workflow, or a remediation is governed as its own operation: approving the outer step does not pre-approve the change underneath it.
Verification separation
The execution result and the verified outcome are separate facts. A provider returning cleanly never produces a verified outcome; that takes an independent observation checked against a declared post-condition, and is reported as unsupported where none exists.
Evidence integrity boundary
Each runtime keeps a hash-chained local audit trail that stays authoritative for its own facts; the central view is an aggregate copy. That detects tampering and corruption in ordinary operation. It is not write-once storage and nothing is cryptographically signed, so it does not prove authenticity against a compromised host.
How these boundaries look from an operating team’s side is on the enterprise governed execution page.
Verification
An agent reporting success is not evidence of success.
Autonomous systems report on their own work, and the report is usually sincere. It is also usually built on a transport signal — a zero exit code, an HTTP 200, a tool call that returned without an error. None of those establish that the resource reached the intended state, and none distinguish a real change from a partially applied one.
A comparison of two accounts of the same operation. On the left, what the provider or the agent says: the call returned without error, so the service is reported as restarted successfully; the source of that claim is the caller itself; what it establishes is that a call completed; and it cannot distinguish a service that started and immediately crashed. The conclusion is that this is an execution result. On the right, what the platform records: after execution, resh re-reads the service and checks it against the post-condition the provider declared, recording whether the outcome was verified along with the observed state; the source is the platform; what it establishes is the state of the resource; and where an operation cannot be observed it is recorded as unsupported, never as verified. The conclusion is that this is a verified outcome, and it disagrees with the caller when the caller is wrong.
This matters most where the blast radius is real: services, configuration, and infrastructure other systems depend on. It is also what makes an automated action reviewable afterwards by someone who was not in the loop when it happened.
Design properties
Where each principle is enforced.
Policy with explicit denial
Rules are evaluated at the runtime before action, and denial is a first-class outcome rather than an error.
Applications without authority
Application scope narrows who may see and ask. The runtime has no concept of an Application at all, which is what keeps a management permission from becoming an execution permission.
Separation of duty
Requesting and approving are distinct, and the requester and approver must be different principals. resh enforces that they are different credentials; your organization ensures they are different people.
Autonomy that ships off
Unattended remediation exists only for single resources and is disabled by default behind several independent switches. Multi-server unattended remediation is refused structurally; no setting enables it.
Evidence as data
The chain from requester and decision through execution and observed outcome is recorded as structured data rather than prose logs, and the runtime that produced a record stays authoritative for it.
Accountability
Six questions, three weeks later.
A useful test of any execution governance model is what it leaves behind. Take an automated change, and imagine being asked about it well after the fact by an incident review or an auditor. These are the questions Activity & Evidence is designed to answer directly rather than by inference.
Who requested the change, and through which Application?
What resource was targeted, and what operation was requested?
What governance decision applied?
Was approval required — and if so, who approved?
What ran — the specific bounded operation, not an approximation reconstructed from a command history?
What state was observed afterwards, and was the intended result verified?
How this differs from an audit log
An audit log is worth keeping, and nothing here replaces one. A typical entry records an invocation: this caller invoked this tool at this time, and the call returned. That establishes that something was attempted. The record resh keeps is built around the change instead — the resource, the governance decision, the approver, the bounded operation that ran, the state observed afterwards, and whether that state met the post-condition the operation declared — as events linked by the request they belong to, rather than entries to be matched up across systems.
Answering these from application logs is usually possible and almost never quick. Activity & Evidence records the requester and the approver as distinct identities, each derived from the credential that was presented rather than from anything the caller supplied.
Current security posture
What is not claimed.
No compliance certifications. resh is a pre-GA design-partner preview and holds no SOC 2, ISO 27001, FedRAMP, HIPAA, or PCI attestation. None is claimed, none is in progress, and the properties described on this page are exercised by the project's own tests — not audited assertions by a third party.
Nothing is cryptographically signed. Content fingerprints on release artifacts and published policy detect corruption and mismatch in ordinary distribution. They do not establish authenticity, and they are not a defence against a compromised distribution channel. There is no write-once evidence storage and there are no signed attestations. That is a stated limitation of the current release rather than an oversight.
No enterprise SSO. There is no OIDC, SAML, SCIM, directory integration, or MFA enforcement today. Operators authenticate with issued API keys. This is the limitation most likely to matter to a security team evaluating resh, which is why it appears here rather than in a footnote.
Applications are not isolation. They are purpose-scoped management surfaces, not tenants. Some read permissions remain estate-wide in this release, so scope operators by environment as well as by Application.
Teams evaluating resh for consequential operations are encouraged to challenge the model directly. The design partner program exists so that security architecture, platform, and SRE teams can test where authorization, policy, execution, and verification break down in real environments — and the full list of what this release does not do is published there.
For security architects
We would rather you tried to break this.
The design partner program exists so security, platform, and SRE teams can push on the model in a controlled, non-production evaluation — where the trust boundaries are messier than any diagram. If you can show us where Application scope, policy, approval, or verification falls apart in practice, that is the most useful thing you could bring us.