Elkwai SolutionsA useful business assistant needs the right tools, not every tool. Define what it may read, what it may prepare and what must remain a separate decision before execution.
| Action | Access to define | Evidence to retain |
|---|---|---|
| Read a business record | Authorized identity, tenant, record scope and environment | Decision, source identity and returned record reference |
| Prepare a draft or proposed update | Draft destination and allowed fields, separate from sending or committing | Draft version, source revisions and review state |
| Send or commit an external action | Explicit action scope and whatever approval your policy requires | Exact approved action, execution identity and destination receipt |
The operator defines the real boundaries and acceptance criteria. A tool name containing "read" does not prove that it is read-only. Keep live controls separate from presentation and model-selected actions.
List exact tools, role labels, required scopes and allowed environments. Decide whether otherwise eligible actions need a separate approval. A missing required scope or wrong role/environment is denied by the supplied policy; approval does not override those failures in this test format.
Do not paste credentials into the tester. Supplied scope labels are hypothetical test inputs, not an authenticated grant. The MCP authorization specification describes an HTTP authorization layer; this calculator does not implement or certify it. Read the MCP authorization specification.
The report identifies untested listed tools. This is a coverage prompt, not an arbitrary readiness gate. Related negative cases, tenant boundaries, resource access and actual approval verification require additional tests in the real system.
Tool annotations describe behavior and are not access controls. The MCP specification says clients must treat annotations as untrusted unless they come from trusted servers. Read the MCP tools specification.
Map authenticated identity to authorization on the server or trusted gateway. Check the relevant tenant, object and action at execution time. When your policy requires approval, bind it to the exact intended action and invalidate it if that action changes. An offline matching test cannot establish that those controls exist or withstand hostile input.
Keep credential validation, payload validation, side-effect reconciliation and policy regression tests separate. Use tool contract review, recorded workflow checks and delivery-effect analysis for their distinct evidence.
Keep the policy version, expected cases, full source-hashed report and private live-control evidence together. Record intended changes before adjusting the tests. A correctly denied test is useful evidence; a high allow rate is not the goal. Do not confuse policy matching with live access, a useful answer or completed business work.
This free browser tool and CLI support exact role/scope/environment conditions and three decisions only. They do not accept raw call arguments or credentials, issue capabilities or connect to a provider. Identifiers and scope labels can still reveal internal operations; review exports before sharing.
This policy tester and its offline CLI are free. The separate $79 one-time Developer Assurance Kit provides five local MCP tools, CLI, SDK and private CI for API/schema changes, payload checks, MCP catalog changes and exact output regression. This policy tester is not included as an MCP tool in Kit 1.1.0.
A separately quoted Elkwai Solutions project can implement a scoped connector, trusted identity mapping, review and execution boundaries, tests and an operating handoff. Agree on the tools, data access, review responsibilities, destination effects and running costs. Model and hosting fees are separate.
Nothing here opens an account, grants access, calls a server, sends a message or starts a paid engagement.