Your AI service needs its own identity and a spending boundary

A service can stop borrowing someone's sign-in

GitHub announced public-preview server-to-server authentication for organization-installed GitHub Apps on October 27. Services using the Copilot SDK can make requests with an installation identity rather than a signed-in user's credentials. The announcement says organization model policies and spending controls apply, with usage charged to the organization owning the installation.

That is a meaningful infrastructure change for teams building automated AI services. A personal sign-in can make a prototype easy to start, but leaves awkward questions when the person changes roles, loses access, or cannot explain a bill. An application identity gives the team a clearer object to manage.

It does not answer every question about what the service should do. Authentication establishes how a request is accepted. Your application still needs to define which work it may attempt, which resources it can reach, and when someone must review a result. Treating those as separate decisions makes the preview easier to evaluate.

This article is a rollout planning guide, not a claim that we installed or tested the preview. The sample service below is fictional: a documentation assistant that prepares draft summaries of changes for a project team.

Before touching credentials, write its purpose in one sentence. If the sentence expands into answering everything, editing everything, and sending everything, reduce the pilot. A service identity is most useful when people can describe the service it belongs to.

Source: GitHub: Copilot server-to-server authentication public preview ↗ · GitHub Docs: Server-to-server authentication ↗ · GitHub Docs: Manage apps using organization Copilot ↗

Name four owners before creating the app; read the permission label in context

Start with the person who owns the service's purpose. For the documentation assistant, that might be the maintainer responsible for release notes. This person decides whether the drafts solve a real problem and which mistakes would make the service unusable. They do not have to be the person who writes the integration.

Next name the technical operator. They handle deployment, runtime updates, failures, and the mechanism for renewing credentials. Give them a contact route that survives a vacation or job change. A project that depends on one person's memory has not gained much operational independence just because it uses an app identity.

Then identify the person who can approve spending. Their job is to understand which organization will pay, what other workloads share its budget, and what action a budget limit actually triggers. A spending alert and a spending stop are different operational outcomes, so record the intended outcome explicitly.

Finally name the person who can suspend the integration. This may be an organization owner, but the important point is that your project team knows who it is and how to reach them. Do not discover that relationship for the first time during an unexpected request storm.

These roles can belong to fewer than four people on a small team. The exercise is about responsibilities, not head count. Put all four responsibilities in the service's short operating note, along with a review date and a link to its owner-approved purpose.

GitHub's administrator documentation highlights an easy misunderstanding: the Copilot Requests permission is labeled Read-only, but requests made under it can consume organization AI credits. Read-only therefore does not mean cost-free. The same documentation says this path is for organization installations, not personal-account or enterprise installations.

For your pilot, create a permission inventory in plain language. One line describes permission to ask Copilot for a response. Another describes access to project content. A third describes any ability to create or change an artifact. Avoid bundling them into a single assertion that the app has AI access.

The fictional documentation assistant might need source material to prepare a draft, but it does not follow that it needs permission to merge changes or contact customers. Decide separately where drafts will appear and who will approve them. A local review file can be a perfectly adequate first output.

Ask a teammate to read the inventory without looking at your code. Can they tell whether the app could spend money, read private content, or change something visible to others? If their answer depends on guessing what a permission name means, improve the explanation.

Also distinguish what the platform can enforce from what your own program merely promises. A statement in an instruction prompt is not the same as withholding a capability. Where possible, make the permitted action set match the narrow pilot. Use the prompt to explain the work within that set.

Choose the authentication path deliberately

GitHub documents different paths for GitHub Actions and other services. Its server-to-server guide says organization-owned Actions workflows can use the built-in GITHUB_TOKEN with the documented permissions and applicable policy. Other services use a GitHub App installation access token. These paths have different setup and policy details; do not combine snippets from both into a guessed configuration.

For the outside-service path, the guide describes installation tokens expiring after one hour. It also explains that disabling automatic logged-in-user discovery requires passing the token through the SDK's explicit token option. A background service should not quietly work only because a developer remains signed in somewhere else.

The practical planning question is how the service behaves when its intended credentials are missing. In the pilot, require a clear failure instead of an accidental fallback to a person's account. The operator should be able to explain which identity would be used for every request before allowing the service to run unattended.

Write a startup check that verifies configuration presence without printing the secret itself. This is a proposed implementation practice, not a complete security procedure. The useful output is an identity or installation reference suitable for operations, plus a clear error when the intended setup is absent.

Follow the current official SDK instructions for the actual code. Preview interfaces can change, and this article intentionally avoids embedding a recipe that might outlive its assumptions. A concise operating note should link to the exact documentation used during implementation.

Design for a request that outlives a token

A service is more than the successful first call. Consider a fictional run that begins with a valid token and then spends enough time preparing material that the token expires before its next request. What should happen to the partially completed work? The answer belongs in the application design.

GitHub's guide instructs services to mint a replacement before expiry and describes restarting the relevant client or runtime for the new token, depending on connection type. Treat that as a lifecycle requirement. Do not solve expiry by repeatedly retrying with the same expired value or by falling back to a stored personal login.

For the documentation assistant, a reasonable design exercise is to save a non-sensitive job identifier and the stage completed. If a run must restart, it should know whether it already prepared a draft. This is especially important if a later version gains the ability to create an external artifact.

Separate failures into categories the operator can act on. Missing configuration, denied permission, disallowed model, and temporary service interruption are different situations. A single generic retry loop can hide all four and make costs or delays harder to understand.

During a supervised pilot, deliberately simulate missing and expired credentials using a safe test setup. The goal is not to trick the provider. It is to confirm that your own service stops clearly, preserves appropriate progress, and avoids duplicate actions. Record what you actually observed rather than assuming a library handles every boundary for you.

A budget belongs to a wider workload

GitHub's app-management documentation says this preview does not provide a budget for each individual app or installation. Organization-level spending controls apply. It also says a budget that merely alerts will not stop further spending; the stop setting must be enabled if that is the intended behavior.

That changes how you should describe a pilot budget. Saying this app has a fifty-dollar cap would be misleading if you have only set an organization budget shared with other activity. Instead, document the actual platform control and any additional limit your application implements.

For the fictional assistant, proposed application limits might include a bounded number of jobs, a maximum input size, a concurrency limit, and a manual switch that pauses new work. These are design suggestions, not promises that the platform exposes each control. Decide which ones your team can implement and verify.

Think through a bad input, too. If a source file triggers repeated unsuccessful processing, will the service keep trying? Set a bounded failure policy and send the item for review. A workload that asks for help after a few failures is easier to manage than one that hides persistence behind an endless spinner.

Discuss shared-budget consequences with other teams before enabling a stop. A control that prevents overspending could also stop unrelated useful work. The person approving the budget should understand that trade rather than discovering it through a project outage.

The point is to make spending behavior explicit at both levels: what the provider enforces and what your application chooses to attempt.

Trace one job all the way to the bill

An organization-owned identity is useful only if you can connect it to actual activity. GitHub says app attribution is available in AI usage CSV exports through app_client_id, which can be matched to installed-app information. Its documentation distinguishes that from what appears in the AI usage view.

Build the pilot around one small supervised job and verify that the expected organization receives its usage. Do not infer correct attribution solely from a successful response. Keep your own job record with a timestamp, application version, task category, and outcome so you can investigate the corresponding reporting window.

Avoid turning that record into a dump of prompts, private source files, or credentials. Start with the minimum evidence needed to answer the operational question. If content logging is necessary, decide who can see it, how long it remains, and why it is needed before collecting it.

For the documentation assistant, useful outcomes might be draft prepared, no relevant change, rejected input, or review required. Those labels explain what the service accomplished more directly than a raw request count. They also help distinguish expensive failure from productive use.

Expect reporting delays and field differences rather than forcing every number to match immediately. Write down the time span and filters you compared. If the records do not reconcile, keep the pilot limited while you resolve the discrepancy. Clear uncertainty is a better result than declaring the accounting correct because the first request worked.

Prepare for a change of team; prove the stop works

A service can outlast its original project. Before that happens, decide what a transfer would require. If the documentation assistant moves to another team, someone should review the purpose, permissions, billing owner, and operational contact rather than simply changing a display name.

Create a short offboarding checklist for the pilot. It should identify pending jobs, saved artifacts, installation access, and any application data that needs retention or deletion under the team's actual policy. The person leaving should not be the only person able to interpret those records.

A handoff is also a useful moment to reconsider whether the service should continue. If nobody can explain the value of its last few outputs, pausing it may be a better choice than preserving it indefinitely. An app identity makes an integration manageable; it does not make the integration necessary.

For your supervised exercise, ask someone who did not implement the service to explain how they would stop new work and identify the billing organization. If they need private knowledge from the original developer, improve the operating note before expanding the pilot. That is a concrete test of whether ownership has actually become durable.

GitHub documents suspending or uninstalling an app as ways to block its installation access, with consequences for that installation's other organization resources. Your team should know those consequences before using the control. An application-level pause can be useful, but it is not identical to removing platform access.

Create a supervised stop drill using a disposable or otherwise suitable pilot installation. Begin a harmless task, pause the application's queue, and verify that no new jobs start. Then test the documented platform control as appropriate for that environment. Record which in-progress work stops and which already-created artifacts remain.

Do not delete logs or drafts to make the drill look clean. A stop action should leave enough evidence to understand what happened. Likewise, do not imply that revoking access undoes an external change the service already made. Reversal of a draft publication, message, or repository change would require its own procedure.

A useful operating note ends with a simple handoff. It names the owner, the billing organization, the expected normal workload, the signs of failure, and the steps to pause and resume. Someone outside the implementation should be able to follow it during an ordinary workday.

The preview's main opportunity is a cleaner relationship between a team and its automated service. Realize that opportunity by making identity, purpose, money, and stopping behavior visible together. Otherwise, a new authentication method can leave the old ambiguity intact, only with a different token.