Webb Technologies · brief for IT and security
How a software or AI project works with your IT and security teams
A summary of how we work on software and AI projects, for the people who review them. The specifics for your project, such as the systems, accounts and data involved, are written into the scope for your project and agreed before work starts.
1.Access we need, and who grants it
We work through the access your team grants, in your own repositories and accounts, and agree with your IT lead up front how access, review and handover will work. For reading your existing systems we ask for read-only, least-privilege service accounts, named and documented, rather than shared or personal logins. The exact accounts are listed in the scope for your project.
Access a software or AI project typically needs and who grants it
- System
- Repositories and CI/CD pipeline
- Access:
- Member access for us during the project
- Granted by:
- IT
- System
- Cloud account
- Access:
- A deployment role for the pipeline; named user access for us during the project
- Granted by:
- IT
- System
- Existing databases, if used
- Access:
- Read-only login to named views; any write-back agreed and tested with your database team first
- Granted by:
- IT (database administrator)
- System
- Sign-in for users
- Access:
- Single sign-on through your identity provider, with roles from groups your IT team manages
- Granted by:
- IT
- System
- AI provider account, for AI projects
- Access:
- An API key for this work only, with usage limits where the provider supports them
- Granted by:
- IT
| System | Access | Granted by |
|---|---|---|
| Repositories and CI/CD pipeline | Member access for us during the project | IT |
| Cloud account | A deployment role for the pipeline; named user access for us during the project | IT |
| Existing databases, if used | Read-only login to named views; any write-back agreed and tested with your database team first | IT (database administrator) |
| Sign-in for users | Single sign-on through your identity provider, with roles from groups your IT team manages | IT |
| AI provider account, for AI projects | An API key for this work only, with usage limits where the provider supports them | IT |
2.Where code, data and infrastructure live
- In your repositories and cloud accounts, from the start. Nothing runs in accounts we control.
- You own all code, infrastructure definitions and documentation. No lock-in.
- We work to your requirements for access, hosting and data, and flag anything we can't meet during scoping.
3.NDA, security questionnaire and walkthrough
- NDA before any engagement. We sign it before any other work starts.
- We answer your security questionnaire and walk your security team through the architecture.
- Where the system connects to your network or systems, the scope includes a data-flow diagram showing each connection and its direction, and a network rule list with the source, destination, port, protocol and purpose of each rule, for your IT and security teams to review before anything connects.
4.Security built into what we build
- Sign-in through your identity provider where your users have company accounts, so your existing multi-factor and conditional access policies apply. Roles come from groups your IT team manages, and permissions are enforced in the application's API as well as its screens.
- Least-privilege access for every service account and login, with no shared or personal credentials in the running system.
- Secrets kept in a managed store, such as AWS Secrets Manager, never in code, configuration files, tickets or email.
- Encryption in transit on every connection, and at rest for the data, files and backups the system stores in your cloud account.
- Logging of sign-ins, deployments and application errors, retained according to your policy, and monitoring with alarms for errors and failures.
- Dependency scanning can be built into the pipeline, with findings shared with your team before releases. What's included is set in the scope for your project.
5.For AI projects: your accounts, your data terms, a person in the loop
- Your own AI provider accounts. We integrate with your own accounts and API keys for Claude, OpenAI, Grok or Gemini, so your usage and data stay under your control.
- Retention and training settings. Your data is governed by your own agreements with the AI providers, and we review retention and training settings with your security team during scoping.
- Only the fields a task needs. We design what gets sent to a model, with sensitive data left out where it isn't required. The data-flow document in the scope for your project shows what is sent to the AI provider.
- Content, not instructions. We design each workflow so text in a document or email, such as instructions to ignore rules or pay a different account, is handled as content to process, not as an instruction: the model gets no more access than the task needs, its output is checked, and anything that touches money or leaves the company waits for a person.
- Usage tracking and limits, so you can see and cap what the AI costs you.
- Human review where output affects customers or money. Items that fail validation or your business rules go to a person, and anything that leaves the company, touches money or is hard to undo waits for a named person to approve it. Every decision and correction is logged.
6.What's handed over at the end
- The code, infrastructure, documentation and access, all under your control.
- Architecture and setup notes, deployment and operations guides, and knowledge transfer with the people who will own it.
- Every account confirmed as yours, secrets rotated, and our access removed or reduced to whatever support is agreed.