Authorize the business action, not unrestricted access to the application.

Begin with a workflow threat model

A useful review names the assets and effects at risk. Which records can the action read or change? What is the largest valid effect? Could a duplicate request create a second transaction? Could stale context apply a valid change to the wrong record? What sensitive data appears on screen, in inputs, evidence, diagnostics, or logs?

The review should also identify trust boundaries: the calling agent, tool server, policy service, application identity, interactive session, operator, and source system. Each boundary needs an explicit authentication, authorization, and data-handling decision. A secure network path alone does not make an overbroad business action safe.

Apply least privilege at two layers

The tool should expose only the operation and fields the agent needs. The underlying application identity should also be restricted as far as the deployed system allows. If the application role can cancel records while the tool only advertises retrieval, a defect or compromised component may still reach more capability than reviewers expect.

Read, create, update, approve, and cancel are separate permissions. Record scope, organizational scope, field allowlists, value limits, operating windows, and current-state preconditions can narrow them further. Access review should cover both the agent-facing contract and the source-system account.

Keep policy outside the prompt

An agent may use policy documents to decide what action to propose, but the action boundary should independently enforce its hard conditions. A prompt instruction is not a durable control against mistaken context, tool misuse, or a different calling agent.

Sensitive operations may require a human approval token, a separation-of-duties check, a value threshold, or a specific role. The policy result should be associated with the request and preserved with the action outcome so reviewers can understand why the operation was allowed or denied.

Treat identity and sessions as first-class design choices

• Authenticate the calling workload and map it to an accountable principal or approved service context.
• Choose deliberately between named, delegated, service, and supervised application sessions.
• Keep credentials and session secrets out of prompts, tool descriptions, and ordinary diagnostic output.
• Define session expiry, step-up authentication, revocation, and concurrent-use behavior.
• Prevent one tenant, business unit, or workflow context from leaking into another session.
• Provide a safe stop and operator handoff when identity state cannot be established.

Verify effects and record useful audit context

A trustworthy action record should connect the requester, tool version, policy decision, accepted inputs, application context, execution outcome, and source evidence. That does not mean logging every screen or every sensitive field. Data minimization, retention, redaction, and access to diagnostic artifacts should match the workflow’s risk and the organization’s policy.

Verification should check the business effect independently of the adapter’s claim that navigation completed. The source evidence may be a read-back, identifier, status, or authoritative report. If the outcome is uncertain, the record should say so and prevent an unsafe blind retry.

Make drift a controlled failure

Interface-backed actions depend on application state, not only visual position. Unexpected screens, changed validation, modified field meaning, new warnings, or unsupported versions should stop the affected action. Continuing by improvisation can turn a maintenance event into a security or integrity failure.

Conformance tests should be tied to the environment and version evaluated. Change management needs criteria for isolation, review, retesting, and resuming writes. The stable agent-facing contract reduces upstream churn, but it cannot remove the need to maintain the adapter.

Questions for a security and procurement review

• What exact records and effects are reachable through each tool?
• How are the caller and source-application identity authenticated, authorized, and revoked?
• Which controls are enforced in code or policy rather than left to model behavior?
• How are secrets, screen data, evidence, logs, and diagnostic artifacts protected and retained?
• How are duplicate requests, uncertain outcomes, and exception handoffs handled?
• Which application or environment changes suspend execution?
• What security documentation and deployment-specific evidence are available for review?

Claims should match evidence

Security evaluation should rely on the architecture, deployment controls, test evidence, and contractual commitments actually available. Graft does not use this page to claim certifications, regulatory compliance, or universal deployment properties. Those questions require current, environment-specific documentation.

The right first step is to scope one workflow deeply enough that access, data, effect, evidence, and ownership can be reviewed without broad assumptions.

Frequently asked questions

Does Graft give an agent full application access?

That is not the intended product model. Graft is designed around narrow actions with explicit schemas, policy, and evidence. The underlying application role must also be reviewed for least privilege.

Are prompts used as the authorization layer?

No. Prompt context can inform agent reasoning, but hard authorization and approval conditions should be enforced at the action boundary.

Does Graft claim a specific compliance certification?

No certification or regulatory claim is made on this page. Buyers should assess current evidence and deployment-specific responsibilities directly during review.

What happens after an uncertain write?

The workflow should check authoritative state before any retry. If it cannot determine the result, it should stop and route the request for reconciliation.

Can sensitive fields be excluded from logs?

Logging should be designed around data minimization and the organization’s audit needs. The exact redaction, retention, access, and evidence design depends on the deployment.