Yes, you should vibe code in the enterprise.

A named business owner is responsible for the application's purpose and continued use.

A named technical owner is responsible for maintenance, fixes and technical decisions.

Both owners have deputies and cover for when they're away or move on.

Write down who the application is for, what it's for and which uses are allowed.

Spell out what the application mustn't be used for and where its scope ends.

The process owner approves the workflow and its effects on other teams.

Assess the impact of incorrect results, data exposure and service interruption separately.

Business criticality determines approval authority, monitoring and support coverage.

Maintenance, licences, infrastructure and future changes have a budget, with someone responsible for it.

A named owner approves the purpose and release policy; you can trace approval of each deployed version through that policy.

The application runs on an organisation-approved platform, such as its own datacentre or an approved Azure environment.

The approval names the subscription, account, tenant or cluster, including allowed regions and services.

Cloud accounts, hosting arrangements and service contracts are under company control.

The environment follows the organisation's security configuration, network design and resource-creation policies.

Public endpoints and internet exposure receive the required approval.

Restrict network access to databases, administration interfaces and internal services.

Control outbound connections, including those to AI providers and external storage.

Development, test and production have separate data, identities and permissions.

Make clear what the hosting provider handles and what your own teams handle for each component.

Prevent deployment to personal hosting accounts or unapproved fallback environments, or detect it and act on it.

The application is registered in the organisation's application inventory, asset system or configuration management database.

The record includes owners, contacts, criticality, data classification and lifecycle status.

Link source repositories, build pipelines and artefact repositories to the same application record.

Servers, containers, functions, databases, storage and scheduled jobs are inventoried.

Record domains, DNS, certificates and who renews them; registrar accounts and recovery channels belong to the company.

The company controls external accounts, service identities, integrations and keys; store references in the inventory, not the secrets themselves.

Dependency records show which business processes stop working when a connected service goes down.

Resource identifiers connect costs, logs and alerts to the correct application.

Check the inventory against what's actually deployed, including manually created or forgotten environments.

Update the inventory when owners, deployed versions or dependencies change.

Each data category has an owner and classification, including personal information and trade secrets.

Collect and retrieve only the data the application needs for its purpose.

Document where data goes, from source systems through the application to external services.

Those flows include logs, caches, search indexes, analytics, backups and support tools.

Know where data is stored and processed, including subcontractors and support access.

Moving data to another region or provider follows the required approval process.

Tests and demonstrations use suitable synthetic data or data whose anonymisation has been assessed.

Any copy of production data used for testing has a justified purpose, suitable safeguards and approval.

Reports, downloads and temporary files keep the classification their contents require.

The data owner has approved confidential-data use in this application and this environment.

Unattended integrations use dedicated service identities; access on behalf of a user keeps that user's identity and authorised scope.

Use short-lived workload identity in place of long-lived keys where it's supported.

Keep required secrets in an approved secrets-management service.

Secrets stay out of source code, browser bundles, URLs, logs and AI conversations.

Every identity receives only the actions and data access required for its task.

Development, deployment, administration and runtime identities are separated.

Administrators use individual accounts and strong authentication; elevated access is time-limited where appropriate.

Track who owns each key, when it expires and how it's rotated. Exercise emergency revocation.

When an employee leaves, remove access through active sessions, development tools and administrative connections.

Emergency access has a controlled procedure, an audit trail and a subsequent review.

Each integration states whether it can read, modify, delete, send, publish or spend money.

Integrations that only retrieve data get read access without unnecessary write permissions.

Write access is restricted to the required objects, records, customers or organisational units.

The receiving system enforces permissions when the caller is an AI agent as well as a human.

Large, irreversible or otherwise consequential actions need human approval suited to their risk.

The approval shows the target, proposed change and expected effect, and applies only to that specific action.

Payments, bulk changes, messages and resource creation have enforceable quantity or value limits.

Destructive operations support previews or dry runs where technically possible.

An administrator can stop automation and revoke its access even when the application isn't working properly.

Have separate procedures for stopping queued work and correcting actions that have already happened.

Coding agents, models, extensions and MCP servers are approved for organisational use.

Check their terms, retention and possible training use before giving them confidential information.

Give agents only the files, directories and network access they need for the task.

Agent execution environments are isolated from production and unrelated projects.

Treat documents, websites and dependencies that agents read as possible sources of malicious instructions.

Code or the platform enforces tool permissions, even when a prompt asks otherwise.

Agents can't grant themselves more privileges, approve their own exceptions or disable required checks.

Changes to agent tools and instructions are versioned and reviewed.

Execution records identify models, changes, checks and approvals without exposing secrets.

Set retention and deletion rules for development conversations, temporary files and logs.

The specification explains what the application does, for whom and under which acceptance criteria.

User journeys cover errors, exceptions and interrupted work too.

Architecture documentation shows components, external dependencies and trust boundaries.

The data model explains meaning, relationships, ownership and lifecycle.

Keep the reasoning behind significant technical decisions, including the alternatives considered.

The threat model and risk register reflect the actual implementation and are updated when it changes.

APIs, events, configuration and differences between environments are documented.

Another developer can run the application from the README without asking its author to explain the missing steps.

Operating, maintenance, recovery and incident instructions are accessible when the application is down.

Documentation has an owner, a review date and a link to the deployed version.

Enterprise users authenticate through the approved identity provider and single sign-on.

OIDC or SAML integrations meet the organisation's identity-provider requirements.

Multi-factor authentication and applicable conditional-access policies cover administrators too.

Provisioning, role changes and removal follow the user's lifecycle through SCIM or another controlled process.

Test that removing a user removes their permissions and ends their sessions within the agreed time.

Sessions have appropriate lifetimes, and administrators can terminate all sessions for a user.

Any required local-password storage and recovery use an approved implementation.

Recovery links expire, work once and resist abuse.

Replacing a lost authentication factor doesn't create an easier way around authentication.

Login throttling, lockout and identifier handling are tested with legitimate unusual inputs and hostile attempts.

Roles match actual responsibilities and define allowed actions precisely enough to enforce them.

The server checks authorisation for every protected operation and data object.

Changing /documents/15 to /documents/16, or calling the API directly, can't expose an unauthorised document.

Tenant and organisational-unit isolation covers background jobs, searches, caches and exports.

Missing permissions or failed permission checks result in a safe denial.

Approvals, payments and access grants follow the required separation of duties.

Support impersonation is restricted, time-limited and auditable.

Guest and supplier access has a sponsor, limited scope and an expiry date.

Owners review access on a schedule based on risk, and whenever responsibilities change.

Identify inherited permissions and escalation paths through groups, role assumption, service identities and integrations; block unintended elevation and test that the blocks work.

The server validates input types, bounds and allowed values, regardless of what the interface checks.

Database access uses parameterised queries or equivalent safe interfaces.

Displayed content uses context-appropriate encoding to prevent cross-site scripting.

The session model's required cross-site request-forgery protection is implemented and tested.

User-supplied URLs can't provide unauthorised access to internal networks or cloud metadata services.

User input cannot become an uncontrolled shell command, filesystem path or executable template.

CORS, cookies, security headers and browser policies match the application's access model.

Remove debug endpoints, default credentials and unnecessary services from production.

Security testing and required independent penetration testing cover the actual operating environment.

Define which findings block release, fix them and retest before approving the affected use.

Network traffic uses encryption appropriate to its classification, with working certificate and peer-authentication checks.

Storage encryption covers databases, disks, objects and backups according to the approved classification.

Encryption-key access, rotation and recovery dependencies are managed.

Check actual file types and size limits on uploads, and run required malware checks.

Uploaded content can't execute with the application's privileges.

File access and sharing links enforce user and tenant permissions.

Archives, unusual filenames and large inputs cannot bypass limits or exhaust storage.

Temporary files and obsolete object versions expire under the retention policy.

Public exposure and changes to storage-sharing configuration are detected.

Assess how data left on workstations, browsers and mobile devices is protected.

The data model is reviewed against business concepts before real information is stored.

Keys, referential integrity, required fields and uniqueness constraints protect correctness.

Schema changes are versioned and repeatable.

Test recovery or repair procedures for migrations; rolling back code won't necessarily bring lost data back.

Assess what happens when a migration holds locks for too long, rewrites data or gets interrupted.

Old and new application versions coexist safely during deployment where required.

Test indexes and query plans with realistic data volumes.

Connection pools, timeouts and limits protect the database from overload.

Concurrent updates and transactions avoid lost changes and partially completed business operations.

Test the model against new tenants and foreseeable next use cases, and record its limits.

Approval limits, delegations and exceptional cases are specified.

One person with several accounts can't bypass a requirement for independent approvers.

Monetary calculations use appropriate integer units or exact decimal representations.

Rounding, currency conversion, negative values and zero follow the agreed rules.

Timestamps, local time and daylight-saving changes work correctly for the use case.

Names, identifiers, Unicode and missing values work without invalid assumptions about users.

Imports handle encodings, separators, invalid rows and partial failures.

Exports contain authorised data and appropriate protection against spreadsheet-formula injection.

Pagination, search and sorting handle changing data without silently losing or duplicating records.

Corrections and any soft deletion follow defined rules and leave the required history.

API contracts, versions and retirement dates are documented.

Incoming webhooks have authenticity and freshness checks.

Receiving the same event again can't unintentionally repeat the same business change.

Operators can see outgoing webhook delivery, retries and failures.

OAuth refresh, revocation and reauthorisation are tested.

External schema changes, missing fields and invalid responses fail in ways the application can handle.

Rate limits protect capacity and provide understandable responses to legitimate users.

Customer API credentials can be scoped, issued, rotated and revoked through controlled processes.

External integration partners have separate test environments and credentials where needed.

Reconcile records across systems to catch silent transfer failures and inconsistencies.

Use a managed queue for slow tasks when the workload needs one.

Jobs have bounded execution time, retries and backoff appropriate to the operation.

A timeout doesn't trigger blind retries when the first attempt may already have changed data.

Jobs that keep failing go to a review queue with an owner and a recovery procedure.

Scaling the application or changing clocks can't accidentally multiply scheduled jobs.

Duplicate events and repeated form submissions are handled on the server.

Interrupted work resumes from a known state or follows a controlled recovery path.

Monitor queue depth, the age of the oldest job and processing capacity.

A dependency failure can't trigger an unbounded storm of requests to other systems.

Replaying jobs and correcting failed batches preserve permissions and required event ordering.

Source code and its history reside in company-controlled version control.

Changes pass the required reviews and checks, with traceable results.

Check package names, publishers, sources and installation scripts to a depth that matches the risk.

Dependency versions and lockfiles support controlled, repeatable builds.

Each release produces a machine-readable software bill of materials, such as SPDX or CycloneDX.

SBOM coverage includes direct and transitive dependencies and runtime or container bases within a defined scope.

Record what the SBOM doesn't cover, including any separately downloaded extensions.

You can connect the SBOM, source revision, build run and production artefact.

Artefact provenance and integrity are checked during release, and repository access is restricted.

Licences, required notices and rights to third-party material are reviewed.

Operating systems, container bases, runtimes, frameworks and libraries have maintainers and a regular update schedule.

Include databases, deployment tools, coding agents and extensions in update responsibilities.

Dependencies and release artefacts are reassessed as new vulnerabilities emerge; SBOM and inventory gaps are investigated.

Prioritise findings by exposure, exploitability and business impact.

Remediation targets reflect severity, with a working route for urgent fixes.

Exceptions and temporary mitigations have owners, reasons and expiry dates.

Test updates against application behaviour, with a way to ship urgent fixes outside routine maintenance cycles.

Verify the fix in the version actually deployed, including any older instances still running alongside it.

Track supplier end-of-support dates and retiring API or model versions before they cause disruption.

The organisation can see which applications are outdated, who owns them and what's blocking fixes.

Infrastructure and environment configuration are versioned, with detection of unauthorised drift.

Test environments reproduce the relevant production behaviour without sharing production credentials.

Pipeline identities can deploy only to authorised environments with the necessary permissions.

Code, test and security checks block releases under defined failure conditions.

You can identify the deployed artefact as the one that passed testing and approval.

Application, configuration and infrastructure changes follow change management, including approved automated routes.

Deployment accounts for permitted downtime, traffic management and database changes.

Rehearse rollback or forward recovery and check data compatibility.

Feature rollout can be limited to appropriate users or controlled with managed feature flags where needed.

You can trace the change, deployer, approval, time and production outcome.

Expected behaviour comes from approved requirements and business examples.

Unit tests cover calculations, state transitions and rule boundaries.

Integration tests cover successful responses, errors and timeouts.

End-to-end tests cover critical user journeys, including consequential approvals and payments.

Negative tests try to bypass object permissions, cross tenant boundaries and escalate privileges both horizontally and vertically.

Add regression coverage for significant defects once they're fixed.

Load testing uses realistic data, concurrency and peaks.

Test selection includes supported browsers, devices, slow connections and enterprise endpoint restrictions.

Agent-reported test results can be checked against actual runs; generated tests are challenged with independent cases.

The process owner accepts the behaviour and known limitations before users depend on the application.

Response-time, availability and data-freshness objectives reflect business needs.

Capacity estimates cover ordinary use, peaks and growing data volumes.

Test scaling and set upper bounds that protect systems and budgets.

Caching preserves separation between users and customers.

Cache expiry and invalidation account for data changes and permission revocation.

Content-delivery services use approved locations and handling rules where required.

You can attribute cloud, model, storage and external API costs to the application.

Unusual consumption alerts a named person in time for them to act.

Know how cost limits actually work and how long enforcement takes; a budget alert doesn't block spending.

Resource exhaustion or budget limits produce predetermined application behaviour.

Searchable structured logs reach an approved central service.

You can trace requests, background jobs and integration calls through the same operation.

Audit records identify the actor, action, target, time and outcome.

Access to sensitive information is logged when the use case or applicable obligation requires it.

Keep passwords, keys and unnecessary confidential content out of logs.

Log access, tamper protection, time synchronisation and retention are managed.

Error monitoring groups related failures and identifies the relevant release.

External availability and transaction checks measure behaviour experienced by users.

Monitoring covers latency, errors, throughput, queues and business-significant failures.

Test that alerts arrive, and review noise, missed incidents and whether escalation works.

The business agrees how much data it can afford to lose and how long recovery can take.

Backup frequency and retention meet those objectives.

Recovery coverage includes required files, configuration and encryption-key dependencies.

Backups are protected against production-account compromise and ransomware.

A restore into a separate environment has succeeded, and you've checked the integrity of what came back.

Point-in-time recovery is available where the data-loss objective requires it.

Exercise recovery of the whole application, including dependencies, at intervals suited to the risk and after significant changes.

Restores account for information deleted since the backup was taken.

Additional datacentres or regions follow continuity requirements, with failover tested where used.

The business has a workable fallback while the application is down.

Support ownership covers the agreed service hours, with on-call coverage where required.

Alerts have severity levels, response targets and escalation routes.

Someone other than the original developer can follow the runbooks for common failures.

Operators can isolate the application, close a connection or revoke an identity during an incident.

A stolen-device or leaked-credential response covers the further access it could give someone.

Investigation evidence is preserved with controlled access.

Responsibilities and applicable deadlines for notifying customers, staff and authorities are documented.

Users have a working incident-communication channel, with an independent status page where needed.

External researchers can find a vulnerability-reporting channel that reaches a responsible person.

Significant incidents lead to corrective actions, with owners and completion tracked.

The model's task, permitted data sources and decision-making authority are documented.

Approve data sent to models against the provider's processing, retention and training terms.

Retrieval, documents and memory enforce user permissions and tenant isolation.

Prompt-injection tests include malicious instructions in files, search results and tool responses.

Validate generated code, SQL, HTML and tool calls, and limit how they can execute.

Run application-specific evaluations and known failure cases before material model or workflow changes.

Model, prompt, retrieval and tool versions are traceable to production.

User and tenant consumption limits constrain runaway use and agent chains.

Plan for model outages and retirement; evaluate fallback models before using them.

Control prompt and response logging, and give uncertain or incorrect outcomes a route to a human.

Users can tell what the application is for, which environment they're in and which object they're acting on.

Empty states, loading and failures have understandable presentations.

Error messages give users a next step without exposing internal information.

A correctable form error doesn't throw away the user's work.

Going back, refreshing or using several tabs doesn't unexpectedly lose data or repeat actions.

Users can tell the difference between a draft, saved information and a completed operation.

Offer undo for reversible actions, or a clear way to correct them.

Keyboard access, screen readers, focus and contrast are checked against applicable accessibility requirements.

The application works on the devices and connections the organisation actually uses.

User guidance, onboarding and feedback channels match the released application.

Supported languages, date formats, numbers and any required right-to-left layouts work correctly.

Reminder time zones, daylight-saving changes and quiet hours work as users expect.

Sending domains are approved, and SPF, DKIM and DMARC are verified against actual application messages.

Test messages with the email clients and filtering systems the enterprise uses.

Bounces, complaints and delivery failures are handled.

Users can manage optional notifications, with mandatory messages identified separately.

Check message content and recipients so information doesn't go to the wrong person.

Support can investigate and perform permitted corrections through a restricted administrative interface.

Routine support doesn't depend on manual database edits or a developer's personal privileges.

Users can find relevant release notes and explanations of what's changed.

Personal-data purposes, legal bases, parties and required processing records are defined.

DPIA applicability is assessed, and required assessments are completed before processing.

Retention, deletion and preservation obligations cover relevant copies, indexes and derived data.

Access, correction and deletion procedures cover connected systems and controlled backup expiry.

Terms and privacy notices describe what the application actually does.

Suppliers, subprocessors, assurance scope, processing agreements and required transfer mechanisms are assessed.

Security-questionnaire answers and applicable assurance reports have evidence, defined scope and responsible owners.

Sector and use-specific obligations are assessed, including relevant GDPR, CRA, AI Act, Data Act, NIS2, DORA or HIPAA requirements.

Applicable healthcare processing agreements and payment-card-data compliance scope are resolved before that use begins.

Contracts cover support, data return, material changes and how to leave the service.

Payments use an approved provider, with card-data handling minimised.

Payment retries and repeated clicks can't accidentally charge twice.

Subscriptions, renewals, cancellations and access expiry work together.

Plan changes and partial-period charges follow the contract.

Control failed-payment retries, reminders and service restrictions.

Invoices contain correct company details, order references and required purchase-order numbers.

Tax, currency and rounding treatment match the relevant sales and transaction rules.

Credits, refunds and partial refunds can be traced to the original transaction.

Usage records, invoice lines, payments and accounting reports reconcile with agreed pricing.

Annual billing and customer-specific terms are tested through contract changes.

Maintenance has access to architecture, development, security, operations and testing expertise, including people who can debug generated code when agents can't fix it.

A second person can build, deploy, recover and diagnose the application.

The code is understandable, its modules can be maintained, and abandoned or unnecessary code is removed.

Parallel development keeps the required checks; the technical owner can stop unsafe releases and changes that break other functions.

Review benefits, usage, costs and emerging risks on an agreed schedule.

New data, integrations, purposes or permissions trigger the required reassessment.

When an owner or supplier changes, transfer access, documentation and the knowledge needed to run the application.

Export required data in a usable format and verify that migration preserves its integrity.

On retirement, close integrations, schedules, identities and resources; handle domains and DNS so nobody can take over abandoned connections.

Retirement updates inventories, contracts and costs; any copies left behind have an owner and a defined retention period.