Base44 Base Code Security: GitHub Access and Shared Secrets

Base44 Base Code Security: GitHub Access and Shared Secrets

Base Code is a shared cloud environment for changing existing GitHub codebases. Before connecting a repository, map who can connect it, change the working branch, open a pull request, merge, and use its credentials. The sharpest detail in Base44’s current documentation is that secrets are encrypted and kept out of the repository, yet shared across all branches. Encryption answers how a secret is stored. Shared scope answers which branches may use it. Those are separate properties, and the second one should shape your test credentials.

This is a control-design guide, not a security review of Base Code. I did not connect an account, inspect a real workspace, or run an access-control test. Base44 documents the product path; GitHub documents branch-protection controls; OWASP provides general guidance for least privilege and secret management. These sources let us build a practical preflight. They do not establish that a specific configuration is secure or that a given repository is protected from every threat.

The main operational mistake to avoid is treating “the AI made a branch” as the entire risk boundary. Base Code’s current support guide says it commits and pushes each AI chat change to the working branch. It also uses connected repositories, workspace roles, project secrets and GitHub pull requests. The guide documents secrets shared across branches, not branch-specific secret isolation. Keep repository access, credential scope, review, merge rights and deployment as separate controls.

Separate the control layers

Base Code involves several permissions that sound similar but govern different actions. The first is the workspace role used to connect a project. Base44’s support guide says owners, admins and editors can connect repositories, and those same workspace roles can access the Base Code project without a separate app invitation. If a teammate is outside the workspace, the docs describe adding them as an app collaborator. A team must decide who can enter the workspace and who should be allowed to work on a given codebase.

The second layer is GitHub authorization. Base44’s setup guide says a private repository must be available to the Base44 GitHub App and that the user needs push access when connecting from the account. If that user has only read access, Base44 documents a “paste a link” route to make a fork or private copy, but then the new work targets that copy. This changes the source-of-truth and integration path, so it is a choice to make deliberately rather than a harmless workaround.

View image detail

Access moves across workspace, repository, branch, and pull request.

Actual size

Choose Actual size to read the graphic closely.

The third layer is the operation on the code. Base44’s support guide says AI chat changes on a synced project are committed and pushed to the branch being worked on. Creating a pull request requires GitHub write access. Creating the PR is not merging it. The PR targets the branch from which the working branch was created, and GitHub runs the repository’s configured checks. Base44 says merging normally happens on GitHub, though its chat can be asked to merge. That capability makes an explicit policy especially useful: document whether a user may request a merge, who is allowed to approve it, and which rules enforce the decision.

The fourth layer is production release. Base44 describes its preview as development-only and says to use the project’s existing deployment process for production. That division can help keep a proposal separate from a release, but it only works if the existing pipeline is configured as expected. The repo’s deployment credentials, CI workflows, hosting controls and runtime configuration can matter even when the initial task is a small interface change. Do not let the word “preview” blur into “staging” or “safe to ship” unless your environment makes that statement accurate.

• Connect the project: Documented control point: Base44 workspace role and GitHub organization/repository access; Question for the repo owner: Who may connect repos, and which organizations are allowed?
• Make AI chat changes: Documented control point: Working branch; changes are committed and pushed to that branch; Question for the repo owner: Which branch is selected, and what credentials can the project use?
• Open a PR: Documented control point: GitHub write access is needed; Question for the repo owner: Who may create or update PRs, and what is the target branch?
• Approve and merge: Documented control point: GitHub review rules and repository merge permissions; Question for the repo owner: Which reviewers, checks, code owners and bypass rights apply?
• Deploy production: Documented control point: Existing deployment process outside the development preview; Question for the repo owner: Which workflow can deploy, from which branch, and with whose approval?

Use the map to name the actor for each action; one “admin” label can hide that a person can connect the repo but cannot merge, or can write code but should not use production credentials.

View image detail

Name each action separately: connect, push, review, and merge.

Actual size

Choose Actual size to read the graphic closely.

Treat a shared branch secret as shared access

Base44’s secret-management documentation says project secrets are encrypted, kept out of the repository, and shared across all branches, including after a rebuild. Changes and removals apply automatically to running branches, while inactive branches receive them when reopened. The docs also support importing .env files, with each KEY=VALUE line becoming a secret and existing names overwritten. These details have practical consequences for team access and test design.

Because the docs do not show a per-branch secret boundary, do not treat a branch as a credential sandbox. If the task needs a key, prefer a development account, read-only permission, or narrowly scoped token compatible with the test. OWASP’s Secrets Management and CI/CD Security guidance supports least privilege and caution with shared credentials. That is general practice, not a Base Code audit.

Before adding any credential, list the code paths that can request it and the people who can change those paths. A token with narrow permissions can still be misused if unreviewed code can send its value elsewhere. The reviewer should understand which integration reads the secret, whether its output is logged, and whether a task can run without that integration. Where those paths are unclear, pause the secret-dependent test and ask the repository owner to map them before proceeding.

View image detail

One project credential may be available across branches, so the test key needs narrow scope.

Actual size

Choose Actual size to read the graphic closely.

When importing .env, treat it as a change to the project’s secret set, not a convenience attachment. Base44 says every KEY=VALUE line becomes a secret and a same-name value is overwritten. Before import, compare a sanitized list of names with current configuration. For each needed name, note the service, test account, permission scope, owner, and why the task requires it. Do not copy values into the review record. Remove production or unrelated entries; leave out any variable whose purpose or owner is unclear.

Ask a developer to trace required variables to their code paths and check for a safe failure when a value is missing. After import, test the intended path without assuming a stored secret was used or that branch names isolate it. Keep optional integrations unavailable during a UI-only trial. Use a scoped development account only when the task needs it, and set an owner and expiry or rotation path. If the task can be tested without credentials, prefer that no-secret route.

• Public configuration: First-trial posture: Use only after confirming it is truly public; Why: No secret-handling decision is needed, but misclassified credentials are still secrets.
• Read-only, development-only API key: First-trial posture: Prefer if the task needs an external service; Why: It limits the consequence of an unintended request or accidental exposure.
• Scoped test credential: First-trial posture: Suitable for a controlled integration check; Why: It should reach test data only, with an owner and an expiry or rotation path.
• Production write key, billing key, administrator token: First-trial posture: Keep out of an early pilot unless a separately approved release process requires it; Why: A branch boundary does not by itself prove the credential is isolated from every collaborator or runtime path.

A development key can still reach real data if its issuer configured it that way. Verify the account, data set, and actual permissions before calling a credential low risk.

Test a credential by what it can do

Credential labels are hints, not evidence. “Sandbox,” “development,” and “read-only” can describe an intended use, but the service issuing the credential defines its actual access. Before a trial, name one action the integration needs and one action it must not be able to take. For example, a reporting task may need to retrieve a test record, but it should not be able to change billing details or delete a customer. Ask the service owner to confirm those limits in the provider’s own settings or documentation. If the account cannot express the boundary you need, the credential is not suitable for that trial.

Choose test data deliberately. A separate test account with synthetic records gives a reviewer a way to see whether the workflow reads or changes the expected object without involving customer data. If the provider has no isolated test mode, use a mock response or a no-secret UI path until the owner has assessed the exposure. “We will be careful” is not a technical limit, and a working branch does not establish isolation when project secrets are shared across branches. Keep production data and high-impact actions out of a confidence-building experiment.

Agree on observable evidence before the run. A reviewer should be able to tell which identity made the request, which test object was in scope, what result was expected, and whether the denied action was actually blocked. Use provider audit events or sanitized application logs when they are available. Do not copy request headers, full payloads, personal data, or raw logs into a broadly shared pull request. A screenshot can show a visible outcome, but it does not prove which identity acted or what permissions that identity held; use the right evidence for each claim.

Define a stop condition as well as a success condition. Stop if the integration asks for a broader permission than the task needs, reaches a real account unexpectedly, exposes a credential in output, or cannot distinguish test data from production data. Do not continue the run merely to gather more evidence after a boundary is crossed. The owner should revoke or rotate the affected credential through its issuer, check the provider’s activity history for unexpected use, and record the response in the restricted incident process. Removing a value from Base Code configuration is useful cleanup, but it is not a substitute for issuer-side revocation or incident handling.

For a small pilot, this evidence can remain short: the identity and test account, the required permission, the allowed and denied actions, the reviewer, and the cleanup result. Add a date or expiry and the person responsible for removing access. If a team cannot name that owner, pause the credential-dependent portion of the test and use a mock or no-secret alternative. OWASP’s secret-management guidance emphasizes ownership, access limitation, rotation and revocation because credentials outlive the immediate coding session; these are general recommendations, not claims about a particular Base Code workspace.

View image detail

Trace a credential from storage to availability and use.

Actual size

Choose Actual size to read the graphic closely.

Keep the pull request as a decision gate

According to GitHub’s protected-branch documentation, branch settings can require reviews, status checks, conversation resolution, signed commits, linear history, a merge queue or successful deployments. They can restrict who pushes and disable force-pushes or deletions. Administrators can bypass protections by default unless the repository enables a stricter setting. GitHub also notes that branch protection rules apply to matching branches and that overlapping rules have constraints; rulesets provide a different control model. The repository owner should inspect the effective rules for the target branch, not assume the organization’s general policy automatically covers it.

A pull request is a place for a decision, not proof of quality. Required checks may be missing, too broad, or green without testing the behavior that matters. A review can be assigned but not completed. A person may approve one diff and then new commits can change it; GitHub has settings that can dismiss stale approvals or require approval of the latest reviewable push. For an AI-assisted workflow, make sure the rule matches how the team expects code to change after review.

Base44 describes existing review and release rules as remaining in place. That is a product statement, not verification of the target repository. Check which actual branch rules apply and whether their required checks test the behavior at issue.

For an initial Base Code trial, define the review package before the change starts. Include a concise PR title and context, linked request or issue, expected behavior, tests actually run, checks still missing, preview URL or screenshots where useful, files affected, secret use, reviewer, and deploy destination. The contributor can provide this record, but the reviewer should validate it. If the PR is too broad to understand, split or reject it. If it introduces an unexpected dependency or workflow permission, investigate before merge.

A second person should be able to follow the proposal without sitting beside the contributor. The request should explain the intended behavior, and the PR should link the evidence for it. If the reviewer must rely on unstated conversations to understand why a file changed, the handoff has not made the decision trail clear. That does not mean every task needs a long report. It means the reason, observed behavior, checks, and remaining unknowns should be concise enough to survive a handoff.

For a change that touches an integration, include the boundary the reviewer can verify: which test identity and test object were used, what action succeeded, and which higher-impact action remained unavailable. Keep this separate from a statement about how the product is designed. A reviewer can confirm the test result from the evidence supplied, while any broader product claim still needs its own source. This small distinction prevents one successful test from being stretched into a claim about every branch, user, or credential.

View image detail

Match review depth to UI, API, or access impact.

Actual size

Choose Actual size to read the graphic closely.

That division of authority is the same operational question explored in Rise Productive’s guide to keeping human review in coding-agent workflows. The products and permissions differ, but the general principle carries over: match each decision to the person authorized to make it and preserve evidence that lets them decide.

A no-production-credential preflight

Before inviting contributors or connecting a sensitive repository, prepare a disposable or low-risk test project. The goal is to confirm the workflow and authorization behavior without giving an experimental branch production reach. A sensible preflight can be written down as a sequence:

1. Identify the workspace role that will connect the repository and the GitHub identity that authorizes access.
2. Confirm the exact repository and starting branch, including whether the workspace permits the organization.
3. Confirm whether the user connects the original repo or a copy, and what that means for review and synchronization.
4. Use a development-only secret with minimum access, or run a task that requires no secret.
5. Create a narrow branch change that does not alter permissions, production data, billing, or deployment settings.
6. Inspect what is committed and pushed to the branch and which checks GitHub runs.
7. Try the pull-request path with the intended reviewer role; confirm who can create, approve and merge.
8. Confirm production deployment is not triggered by opening the preview or PR, unless the team’s tested release process explicitly says otherwise.
9. Remove or rotate test credentials when no longer needed, then document the owner and results.

This is a proposed procedure, not a claim that it was completed. If the product cannot be tested in a disposable repo or without sensitive credentials, ask the repository owner or security lead to review the setup first. A test that requires production privileges is not automatically safe just because the code is on a working branch.

View image detail

Check review, automated checks, and merge as separate gates.

Actual size

Choose Actual size to read the graphic closely.

For a credential-removal test, record who can remove the value, which running branches receive the change, what an inactive branch receives when reopened, and how its issuer confirms revocation. Base44 documents the update timing; the external provider determines whether the old credential is actually revoked.

Match controls to the consequence of the change

Not every task needs the same review burden. A text-only update on a read-only internal help page can often be reviewed differently from a task that changes role checks or payment processing. But the team should decide that before the experiment; do not let the model’s chosen files determine the impact classification after the fact.

• Copy, static layout, empty state: Example first-trial limit: One route or component, no data behavior changes; Review focus: Visual preview, links, responsive widths, changed files
• Form behavior: Example first-trial limit: Test dataset, no sensitive or production writes; Review focus: Validation, input handling, permissions, tests and data destination
• External API integration: Example first-trial limit: Scoped test key and mock or test service; Review focus: Key scope, request behavior, logging, error handling and revocation
• Authentication, roles or payment: Example first-trial limit: Keep out of the first confidence-building task; Review focus: Domain-owner review, security tests, test identities and controlled release
• CI/CD or deployment configuration: Example first-trial limit: Keep out of a small feature pilot; Review focus: Workflow permissions, environment protections, secrets and release trigger

Classify by consequence, not file count: a small change can expose customer data, while a broader visual change may have no data or release effect.

View image detail

Preflight the user, branch, required checks, and cleanup.

Actual size

Choose Actual size to read the graphic closely.

Record what is known and what remains open

Base44’s support guide documents workspace roles, GitHub connection paths, working-branch changes, preview limits, PR permissions, and secrets shared across branches. GitHub’s guide describes available protected-branch controls; OWASP gives general access and credential-lifecycle guidance. These sources support a practical control map, not a security verdict for a particular project.

Some product questions remain unanswered by the reviewed docs: which identities can use a secret at runtime, what execution logs reveal, how repository code is isolated, and what retention or incident policies apply. If any unknown matters to the repository, assign it to an owner and ask for the current policy or control description. Record whether each answer came from documentation, settings inspection, or behavior observed in the test. Keep the record in an access-controlled location; use sanitized screenshots or log extracts and never include a token, .env value, customer record, or private prompt.

At closeout, note the temporary credential’s owner, removal status, and whether its issuer confirmed revocation. Base44 documents when its project secret is removed from running and inactive branches; the external provider determines whether the old credential itself is revoked. Keep those outcomes separate. A clean configuration change is not proof of end-to-end credential revocation.

Frequently asked questions

Does Base Code merge changes automatically?

Base44’s documentation says opening a PR does not merge it and that merges normally happen on GitHub. It also says a user can ask the AI chat to merge a pull request. Check the repository’s settings and the team’s operating policy to see which identities can merge and what controls are required.

Are Base Code secrets isolated by branch?

The reviewed Base44 documentation says secrets are shared across all branches. It does not document per-branch secret isolation on the page reviewed. Use appropriately scoped development credentials and verify current product behavior before a sensitive test.

Is a pull request itself a security control?

A PR is a review surface. Enforcement depends on required reviewers, status checks, branch rules or rulesets, merge permissions and any bypass settings on the target repository. Inspect the actual configuration instead of assuming the PR button enforces a policy.

Can a read-only GitHub user connect a repository?

Base44 says users can paste a repository link to create a fork or private copy when they cannot push to the original. In that case, the copy is connected and PRs target it. Confirm that this copy path matches the team’s intended source of truth and review process.

Keep the conclusion tied to this setup

Before a collaborator joins, use the record below to identify which controls are documented, checked, or still open for this repository. The result is a map of one setup, not a blanket security verdict.

View image detail

A security evidence note distinguishes documented, checked, and open controls.

Actual size

Choose Actual size to read the graphic closely.

The note should travel with the change only when its audience has access to the details. A public issue or general-purpose PR may be visible to people who should not see internal hostnames, account identifiers, or incident context. Keep sensitive operational evidence in the team’s restricted system and link to it only for reviewers with permission. In the article or PR, retain the decision-relevant summary: which source supports a statement, what was tested, what remains unknown, and who owns the next step. That preserves reviewability without turning the evidence record into another place where secrets accumulate.