KNOWLEDGE / TIPS / POINTS / LINKS
The same topic registry powers these articles and the ? buttons in MCPaios. Product information is public; tenant records and authority operations require sign-in.
MCPAIOS / KNOWLEDGE BASEThe human work surface for seeing current machine authority, pending human decisions, machine identities, receipts, and reconstruction evidence.
Start here when you are unsure what needs attention next.
The Control Plane governs authority state. It does not perform the protected machine action itself.
Record a human decision that an exact proposed authority scope may become a grant.
Read actor, actions, targets, validity window, intent, and policy binding before ratifying.
Ratification authorizes the proposal to become authority; it does not execute the requested action.
The canonical bounded authority record that states what a machine actor may do, against which targets, under which policy, and for what time window.
Open a grant whenever scope, ancestry, expiry, or revocation status is unclear.
A credential can authenticate a caller, but the credential is not the grant.
The exact machine identity named by the grant and request.
Treat actor identity as an exact binding, not a descriptive label.
A request from a different actor must not inherit authority merely because it can reach the same service.
The human or governed principal under whose authority the machine grant exists.
Use the principal to understand who the machine authority ultimately belongs to.
Delegated grants preserve the principal boundary required by the pinned MCP2 protocol.
A cryptographic digest binding the grant and verification request to the exact governing policy material.
A changed policy should produce a changed digest rather than silently changing old authority.
A policy label alone is not sufficient. The digest is the integrity binding used by authority verification.
The last-responsible-moment authority boundary immediately before a protected action can execute.
Keep target credentials and execution capability behind the fence.
Only an exact current receipted ALLOW may cross the protected execution boundary. Timeout, malformed authority, or required-state failure fails closed.
A machine identity role that may submit bounded proposals and materialize only authority already ratified by a human.
Keep operator and fence credentials separate.
An operator does not gain human ratification authority.
A read-oriented machine identity role for receipts, reports, authority events, and reconstruction.
Use an auditor credential for evidence review instead of reusing an operator or fence credential.
Audit access does not imply execution authority.
Durable evidence of an authority verification decision, including protocol and request/grant bindings.
Use the receipt ID as the starting point when investigating a past ALLOW or DENY.
A receipt is evidence of the decision; reconstruction may also require the applicable canonical records and profile evidence.
Rebuild the historical authority context for a receipt so an auditor can understand why the decision was made and what happened afterward.
Start with the receipt ID rather than trying to infer history from current grant state.
Historical validity and current eligibility are different questions. Reconstruction preserves that distinction.
Prospectively invalidate machine authority so future protected execution cannot rely on the revoked grant.
Record a clear revocation reason; it becomes part of the authority evidence.
Revocation does not erase historical receipts or pretend a previously valid execution never happened.
One-time bearer material used to authenticate a machine identity to MCPaios.
Store plaintext only in the calling service secret manager. MCPaios stores the hash, not the reusable plaintext.
Credentials authenticate. They do not create or expand machine authority.
The unique identifier for one durable MCPaios authority decision receipt.
Copy the receipt ID from Evidence when you need to reconstruct or audit a decision.
The ID locates the evidence record; it is not itself the proof material.
The exact operation the machine is asking to perform. Authority is evaluated against this exact action, not a broad description of what the machine can do.
Keep action names narrow and stable so a grant says exactly what is permitted.
A grant for one action does not authorize a different action merely because both use the same service.
The exact protected resource, service, record, tool, or endpoint against which the action would occur.
Use the narrowest target identifier that still describes the intended protected resource.
Authority for one target does not automatically extend to neighboring resources or another environment.
The period during which a grant may be considered for execution-time authority verification.
Keep the window no longer than the work actually requires.
Verifier time controls current eligibility. A request timestamp does not extend expired authority.
A bounded child grant derived from existing authority without exceeding the parent grant’s principal, policy, actions, targets, or validity window.
Inspect the parent chain whenever delegated authority behaves differently than expected.
Delegation can narrow authority; it cannot silently broaden it.
The append-only sequence of governed authority events used to preserve how the current machine-authority state came to exist.
Use the revision, sequence, and ledger head when comparing two snapshots of authority state.
The ledger preserves history; changing current authority does not rewrite earlier events.
The rule that reusable plaintext machine credentials stay with the calling service, while MCPaios retains only the hash needed to authenticate them.
Copy a newly issued bearer token directly into the caller’s secret manager before leaving the one-time view.
Do not place bearer credentials in source code, chat, screenshots, tickets, or logs.
The fixed machine identity role—operator, fence, or auditor—that determines which MCPaios API operations a credential may call.
Create separate identities for separate duties instead of sharing one credential across roles.
A role controls access to MCPaios operations; grants still determine what a machine actor may actually do.
The exact MCP2 Candidate version and public commit that this MCPaios deployment is qualified to implement.
Use the protocol endpoint when auditing which MCP2 semantics a receipt or deployment is using.
MCPaios implements the pinned MCP2 protocol; it does not redefine MCP2.
The result record bound to a receipted ALLOW after the protected target has attempted execution.
Treat missing completion evidence after ALLOW as a condition to investigate rather than assuming success.
Authority to execute and evidence that execution completed are distinct facts.
A single-use request value used with tenant and grant context so an accepted protected request cannot simply be replayed.
Generate a fresh nonce for each new protected execution attempt.
Replay protection is part of the execution boundary; reusing a consumed nonce must fail closed.
An identity-bound role in the MCPaios human authority organization, such as owner, authority administrator, approver, or auditor.
Grant only the human role required for the person’s actual governance responsibility.
Human membership governs authority decisions. It is separate from machine service credentials.
A non-authoritative invitation that allows a specific verified person to claim an offered human role.
Check the email, role, and expiry before sending an invitation.
An invitation grants no authority by itself. Membership exists only after authenticated claim.
The target-owned boundary where a protected action is allowed to proceed only after a current durable MCPaios ALLOW.
Keep target credentials and the execution callback on the target side of the fence.
MCPaios deliberately has no generic /execute route.