# Plan access without database roles

Coordinator DB authenticates named users, but roles, grants and per-table permission policies are unavailable. Commands such as `GRANT`, `CREATE ROLE` and `SET ROLE` are not a substitute for an application access design.

Start by identifying who may submit SQL directly and which operations their reader task actually requires. Use explicitly configured credentials for the service, restrict network reachability, and have the application enforce permitted operations when end users should receive a narrower interface.

For example, an application can expose a fixed report query and validate its inputs before sending SQL. A view can make that query easier to maintain:

```sql
CREATE VIEW public_product_names AS
SELECT id, name FROM products;
```

The view does not create a security boundary for a user who can query the base table directly. Do not treat omitted columns as protected merely because a report hides them.

Review HTTP and native credentials independently of any application login. Native requests authenticate before SQL is accepted; HTTP supports configured Basic credentials or Bearer keys. Credentials travel without built-in TLS, so use trusted connectivity or an external secure transport.

See [authentication and network access](https://coordinatordb.com/docs/concepts/features/security), [HTTP authentication](https://coordinatordb.com/docs/concepts/features/interfaces/http) and [views](https://coordinatordb.com/docs/reference/statements/create/view).