Give people room to act. Protect the boundaries around them.

Signing in establishes identity. It does not, by itself, establish which job, employee or location someone may access. We design permissions at the levels the business requires: organisation, role, team, object and action.

In practice: initiative for young people, a distinct role for parents

For KidsJobs, we developed the entrepreneur’s vision into the product, app and backend. Customers post jobs, young people respond, and parents have a distinct relationship with their child’s account. A generic “user” role would not describe those responsibilities.

We modelled the accounts, their relationships and the progression from a posted job to an assignment. This is where a permission model starts: understanding who someone acts for and what they need to do independently.

Access also has a lifecycle. A changed role, a departing employee or an ended partnership must change what the account can do.

Important actions need validation even when a request bypasses the interface and goes directly to an API.

For a property services platform, we built applications for property managers, service providers and workers. The backend operation for creating a shared work order checks identity and administrative context. The mobile application retrieves work within a provider, worker and date context. A single job connects separate organisations with distinct responsibilities.

In the application and partner platform, commission-batch registration has an explicit administrator check in the API. The permission boundary exists in the processing operation, not just in the portal.

For direct Firestore access, we design appropriate Security Rules. Server libraries do not automatically pass through those rules, so backend authorisation and IAM require their own implementation and tests. Google documents the distinction.

App Check provides an additional layer for app or device authenticity. It does not replace user permissions. Google explains its complementary role.

What information does an operation actually require? Who needs to see it? How long should it remain available? Does it also appear in exports, logs, backups, test systems or AI requests?

We map those flows and turn agreed requirements into design choices: limiting personal information in logs, protecting stored files and using appropriate test data.

For a European business, choosing where data is stored is one part of the design. We also examine which providers process it, who can access it and what happens in support systems, logs and backups. A European server region does not settle all those questions. We translate the agreed privacy requirements into the platform and document the choices for your team's review.

The same questions guide our private AI approach. We prefer open models in a private environment and select the model and hosting together. The application determines which business information it can use; choosing a model does not give it access to everything.

An integration or background job should receive the access its task requires. A service reading information does not automatically need permission to delete records or initiate financial transactions.

Secrets do not belong in frontend code, repositories or ordinary logs. Credential management, environments and access ownership form part of the handover. For sensitive administrative actions, we agree additional verification and separation of responsibilities where needed.

A passing test for an authorised user is only part of the evidence. We also need to know whether a different organisation is denied access, revoked permissions are respected and invalid state changes are rejected.

Depending on the engagement, this includes:

• A map of data, roles and important risks.
• Tests for permitted and denied actions.
• Dependency, configuration and sensitive-data-flow checks.
• Review of critical changes and recovery options.
• Agreed security reporting and maintenance responsibilities.

Higher-risk applications may require an independent penetration test. The depth follows the consequences of a failure.

An assistant acting for someone must respect the same boundaries. We define its available sources, the operations it can prepare and the actions requiring explicit approval.

Authorisation belongs outside the language model. OWASP makes the same distinction in its guidance on excessive agent permissions. Excessive agency guidance. Our agentic architecture approach explains how that translates into a product.

People, software and providers change. Updates, access management, monitoring and incident responsibilities therefore belong in the operating agreement.

We make clear what we maintain, what your organisation owns and which checks must be repeated after a change. The result is a security approach your team can understand, test and manage. Discuss the technical responsibilities for your platform.