OTAOpen Technology/App

Setup / Security / Control / Usage

Understand what your AI can do.

The AI Control Layer connects the documentation used to build the app with its executable permissions and the evidence used to describe it.

Source review: September 13, 2026. These labels describe inspected implementation. Hosted availability also depends on the deployed version, account permissions, feature flags and provider configuration.

Set up by responsibility

  1. Platform owner: verify the deployment, provider configuration and test environment. Hosting and database permissions are separate from app permissions.
  2. Organization admin: check the supported connection controls, membership and available features. Verify the intended organization and project before testing.
  3. Project creator or member: start with synthetic items in an authorized test project. Ask for a summary, compare it with the underlying items and check the project scope.
  4. Reviewer: repeat with a restricted account, check unavailable or foreign-project requests, remove temporary records and revoke test credentials when finished.
Full setup and API guidance

Capability and control map

Implemented in source

Context follows scope

The organization assistant and project-bound memory threads have different scopes. Ordinary organization reads are restricted to the organization; viewer reads depend on ownership. The platform owner has a diagnostic exception. Project-bound context remains limited to its selected project.

Implemented in source

Read and navigate tools

The current tool dispatcher can query items, summarize projects, summarize activity and return navigation. These tools do not create, edit or delete items, and navigation does not execute an automation, playbook or sync.

Feature-gated in source

Reviewed project memory

Project memory distinguishes proposals from active approved entries. Access, sharing, expiry and the feature flag matter. Confirm availability and permissions in your target account before relying on it.

Configuration required

Provider setup and testing

Supported provider paths still need suitable credentials and configuration. The admin model preflight disables tools and app data. A successful model check does not prove every workflow or data boundary.

Planned

Confirmable AI writes

The canonical AI proposal reserves mutation tools for an explicit design and review of permission checks, confirmation, audit, idempotency and reversal. A chat request alone does not supply this capability.

Planned runtime connection

Repository docs inside app chat

The build workflow links repository docs, generated agent instructions and proposals. The inspected app assistant does not automatically retrieve those repository documents. Its existing knowledge artifact is based on app data.

From README to reviewed change

  1. README and manual setup identify the task, prerequisites and permissions.
  2. Agent instructions guide implementation through one canonical proposal queue.
  3. Generated agent docs inherit the source instructions; generated references retain their coverage limits.
  4. Code review, tests and deployment evidence establish which claims the app docs can make.
  5. Reviewed marketing explains those capabilities. Feedback and verified news can inform future proposals.

Documentation guides work. Server checks enforce access. Imported documents and model output cannot grant permissions.

Try a small, verifiable request

“Summarize overdue items in this test project. Show which items support your answer. If the data is unavailable, say so.”

Check the referenced records and scope. If a provider fails, record the error without pasting secrets into chat. A fluent answer does not prove permission checks, successful writes or current pricing. Confirm provider data-handling terms before sending sensitive material.

Explore the AI learning library →