Wrap the GitHub Copilot SDK in an Action Envelope Before It Reaches Your Application

GitHub released an MIT-licensed multi-platform SDK for integrating the Copilot Agent into applications. A developer advises wrapping the SDK in an action envelope to enforce authorization, idempotency, and revision control, ensuring the application retains authority over agent-proposed actions.

GitHub has published github/copilot-sdk https://github.com/github/copilot-sdk , an MIT-licensed multi-platform SDK for integrating the Copilot Agent into applications and services. Embedding an agent is not the hard part. Connecting its proposed actions to your application's permissions, persistence, and UI is. A safe full-stack path starts with an action envelope that every layer understands. type AgentAction = { actionId: string; actorId: string; operation: "read file" | "propose patch"; resource: string; baseRevision: string; arguments: Record<string, unknown ; expiresAt: string; }; The model may propose this object. It does not authorize it. Validate the envelope at the server: function authorize action: AgentAction, user: User { if Date.parse action.expiresAt < Date.now throw new Error "expired" ; if action.actorId == user.id throw new Error "actor mismatch" ; if action.operation === "propose patch" && user.canWrite action.resource { throw new Error "forbidden" ; } } Resolve identity from the authenticated session, not from model output. Bind the action to a base revision so a later repository state invalidates stale approval. Store proposed and executed states separately: php proposed - validated - approved - executing - succeeded \- failed Use actionId as an idempotency key. A network retry must return the existing result instead of applying a patch twice. Before approval, show: If the plan changes, create a new action ID and require new approval. Do not silently update an approved card. Keep Copilot-specific request and response types inside one adapter. The rest of the application should depend on your AgentAction contract. That gives you a stable authorization and persistence model if the SDK, model, or provider changes. This is an integration pattern, not a claim about the SDK's internal authorization, session, or persistence behavior. I have not built a production application with the current SDK release. Check the repository's supported languages and current API before implementing the adapter. An agent SDK supplies capability. Your application still owns authority.