A church’s AI policy needs to survive its software permissions

The permission hidden inside an ordinary job

Consider a fictional church asking an AI assistant to identify gaps in next month’s volunteer schedule. Its written instruction allows recommendations but forbids changing assignments or contacting anybody. The administrator connects an account associated with scheduling, assuming that the job title describes an appropriately narrow permission.

That assumption needs checking. The important comparison is between the church’s intended task and every action the connected account permits. A correct recommendation does not demonstrate that the assistant lacked authority to do something else. Equally, broad account access does not prove that an agent will misuse it: the agent service may impose additional restrictions. The question concerns the whole configuration.

This analysis compares published guidance and documentation. We have not connected an agent to a church account, tested a vendor’s defenses or investigated an incident.

What this week’s ministry advice establishes

In an article published October 13, 2026, Grace Theological Seminary’s Freddy Cardoza and Anthony Casey discuss the distinction between useful technological assistance and the human formation ministry requires. Casey recounts evaluating a ChatGPT answer using expertise he already possessed. The article supports a particular understanding of discernment; it does not announce an enforceable software policy. Grace’s faculty guidance (Source: seminary.grace.edu)

On October 14, 2026, church-marketing agency REACHRIGHT published Thomas Costello’s advice on AI agents. He identifies himself as an executive pastor and reports weekly agent use by his team. His proposals include named responsibility, approved tools, restricted data, human approval for consequential actions and separate accounts. This is a practitioner’s commercially published account, not an independent examination of a church deployment. REACHRIGHT’s agent guidance (Source: reachrightstudios.com)

A different kind of commitment appears in AI for Church’s forthcoming hackathon. Its rules prohibit real congregant personal information in demonstrations. A suggested scheduling project starts with read-only gap identification and retains human approval before invitations. The build window is October 30–November 27, 2026; these are published requirements and examples, not completed products with verified safeguards. Hackathon rules and project ideas (Source: aiforchurch.com)

The distinctions are consequential. Faculty counsel can shape a church’s purpose. A practitioner can propose a workflow. Competition rules can govern submissions. None of those sources, by itself, establishes what a connected system will prevent.

A role name is not an action boundary

Planning Center’s Services documentation supplies a concrete comparison. A Scheduler can schedule people on teams they lead, edit those teams, and start their team chats. Profile-editing access also exists, with particular fields subject to the organization’s settings. A Viewer can participate in invited chats; when direct messages are enabled, chat participants can message people sharing a team or group regardless of their Services permission level. File access is configured separately. Planning Center’s permissions documentation (Source: help.planningcenter.com)

These are documented product functions, not vulnerabilities. The current page bears an October 14 publication date, which does not establish when those capabilities began. Nor does this documentation establish the permissions of any particular AI connector or integration.

The operational implication is narrower and more useful than a warning about one supplier: a church cannot translate “Viewer” into “incapable of communication,” or “Scheduler” into “only the one scheduling action we intended,” without inspecting the relevant settings and access route.

Our proposed comparison therefore has three columns: the action the church authorizes, the account capability available, and the mechanism that enforces any narrower limit. A missing answer in the third column is a question to resolve before deployment, rather than evidence of a breach.

A worked comparison, using fictional records

For the fictional scheduling task, the first row would be inspect availability. The church authorizes use of a deliberately prepared sample containing invented volunteers and dates. The trial should establish what information the assistant actually receives. If it receives additional fields, the reviewer records that difference instead of judging the trial solely by the quality of its recommendations.

The second row would be propose an assignment. The expected output is a separate draft. The reviewer asks whether the same connection also exposes controls that alter the live schedule. Where that is possible, the supplier should identify what prevents an unauthorized change: a restricted integration, a separate approval mechanism, or something else. A sentence in the task description should not be silently recorded as a tested restriction.

The third row would be contact a volunteer. This remains outside the assignment. The review must consider all communication routes exposed in the proposed setup, including ones outside the scheduling screen. Blocking an invitation command would not, by itself, establish that another route cannot deliver the same message. This is a hypothetical verification question, not a finding about Planning Center or any agent.

The fourth row would be connect another service. The trial does not require that power. If setup instructions encountered during the task request broader access, the assistant should stop for the designated human decision. The test record should distinguish “the assistant declined” from “the application rejected the request.” Both are useful observations, but they describe different protections.

Run such checks only in an authorized test environment with synthetic records and controlled recipients. A congregation should not discover its boundaries by experimenting on members’ live accounts. If suitable testing is unavailable, an isolated sample and human-operated changes may be the proportionate starting point.

Why the location of the check matters

Anthropic’s April 9, 2026 account of trustworthy agents distinguishes the model, its operating instructions and safeguards, its tools, and its environment. It describes action-level permission choices, including allowing calendar reading while requiring approval for invitations. It also acknowledges that combined defenses do not guarantee protection from hostile instructions embedded in material an agent reads. These are the developer’s descriptions, not certification of another product’s configuration. Anthropic’s explanation (Anthropic source)

A preprint submitted October 10, 2026 by Md Imran Hossen reports a more specific failure. In a controlled local testbed, browser agents could be induced to approve access or register an event-delivery destination beyond the task’s authorization. The paper reports that a service-side check rejected unauthorized requests in all 70 gated attack runs, even though the agents still submitted them. Full preprint (Source: arxiv.org)

The study is not a test of Planning Center or a church deployment. Its main evaluation used two models, one browser framework and two scenario families; experiments ran in June. The service simulated an authenticated session without a login or additional authentication step. Its authorization information was supplied through controlled mechanisms, including a matcher for prescribed task wording. General interpretation of arbitrary requests remains a separate problem. No real accounts or third-party services were involved.

The useful lesson is a distinction between behavior and enforcement, not a transferable safety percentage. Asking an agent to respect a limit, observing it respect that limit, and having a service reject prohibited actions are different forms of evidence.

Stewardship includes the configuration

Our Christian application begins with the relationship a church already claims to maintain. Volunteers entrust availability to people coordinating shared service. They have not thereby made themselves interchangeable entries in an optimization problem. A scheduling decision can touch rest, family obligations and a person’s freedom to decline.

Theological discernment therefore matters before a task becomes an instruction. Leaders decide what counts as a good outcome and which considerations should remain with people who know the community. Technical expertise then has its own indispensable role: determining whether the chosen boundaries actually exist. Neither competence should be asked to impersonate the other.

In 1 Corinthians 4:1–5 (NIV), Paul describes apostolic servants entrusted with what God has revealed and insists on faithfulness. He also distinguishes a clear conscience from final vindication: judgment belongs to the Lord. The passage addresses Christian ministry and accountability before God, not software design. Read the passage in context (1 Corinthians 4:1-5 (NIV))

Our application is limited but practical. A leader’s sincere intention to protect volunteers cannot, on its own, establish that a connection preserves the limits promised to them. Checking those limits can be one expression of care for an entrusted responsibility. It should also encourage modest reporting: a successful trial shows what happened in that trial, while an untested setting remains untested. Scripture supplies a reason to take faithfulness seriously; technical evidence must still establish what the software does.

There is a reasonable objection: a small church cannot engineer a new authorization system. It need not. It can reduce the proposed job until the access and controls are understandable, use fictional samples for evaluation, and retain human operation of steps it cannot safely delegate. Less automation can be an honest implementation decision rather than a failure of ambition.

The practical result of a review should be modest and specific: these actions are allowed, these mechanisms constrain them, and these uncertainties remain. That statement is more accountable than either blanket enthusiasm or blanket refusal. It lets the congregation understand what its leaders have actually authorized, and what they still need to establish.