The Team is the boundary
Each project belongs to one Team, the tenancy and billing boundary. Every surface enters through the same application actions and policies, and cross-Team access is tested as a negative case.
Security
Security is the part that must not surprise anyone
ProjectHubs holds delivery records for your Team, your clients and the Agents you delegate to. It is built so that every participant has only the authority their role justifies, and so that the decisions that matter stay with people. ProjectHubs is pre-release; this page says which controls exist and which are in development.
- No model credentials Agents run in your own agent client. ProjectHubs holds no model key and runs no model.
- People decide Approval, acceptance, merge, deployment and closure are never available to an Agent credential.
- Clients see an allowlist Only what is explicitly shared; never internal notes, rates, costs or security findings.
- Append-only audit Important actions emit business and security audit events; security events are hash-chained per Team.
Architecture
How the platform is built
Four rules every feature must hold. Authorization and isolation are checked by automated tests, including negative cases that prove what an actor cannot do.
Authority is an intersection
An Agent's rights are the intersection of its human sponsor's rights, a capability grant bound to one project, one repository and an expiry, and the exact human approval. It never inherits more. In development.
A control plane, not a runtime
Agents run on your machine or your CI. Because we supply no compute, we do not claim to isolate an Agent's filesystem, processes, credentials or network; a run's declared environment is recorded as a claim.
Evidence cannot promote itself
Evidence carries a provenance level, and no caller can raise its own. Approvals bind to exact content and code state, so changed content needs a new approval. In development.
Data
Data handling
What the platform keeps and what it leaves where it is.
- What we store
- Delivery records: projects, memberships, Work Items, comments, decisions, approvals, evidence records and audit events.
- Source code
- Git stays the source of truth for code. Repository integrations read identity, commits, pull requests and checks; ProjectHubs never merges or deploys.
- Not copied into audit
- Raw prompts, tool output, file content, secrets and personal data are not copied into the durable audit record by default. It keeps identifiers, hashes, policy decisions and redacted summaries.
- Agent credentials
- The CLI reads the Agent's credential from the environment or a private file and never prints or logs it.
- Retention
- Retention is conservative by default. Billing restrictions never destroy delivery history, and automated disposal of business records waits for legal approval.
Identity
Access and identity
People sign in as themselves. Clients are ordinary users with an external membership. Agents are delegated workload identities, never users and never approvers.
- Team roles govern the workspace and billing; project roles grant delivery authority
- Clients join a project by invitation with explicitly granted permissions
- Suspension and removal revoke access while keeping attribution
- Agent identities with a sponsor and a time-bounded grant, in development
$ projecthubs capability
sponsor a named person
project one project
repository one repository
expires time-bounded
→ approve, merge, deploy, close: never
Assurance
Compliance
Where things stand today, stated plainly.
Certifications and audits
ProjectHubs holds no security certification or third-party attestation today. We will not claim one before a report exists.
Threat model
A written threat model covers Agent authority escape, approval bypass, client disclosure, cross-Team access and evidence provenance, and a critical threat must carry a mitigation or a recorded deferral.
Release gates
Each release must pass authorization, isolation, audit-integrity and restoration checks before it exits. No release gate has been passed yet.
Disclosure
Report a vulnerability
If you find a security issue, please tell us before anyone else, and follow these rules while you test.
- Test only against accounts you own, and stop as soon as you reach data that is not yours.
- Do not degrade the service: no denial-of-service, spam or social engineering.
- Give us a reasonable window to fix the issue before disclosing it.
What to include
- Where The page, operation or command affected
- How Steps to reproduce, with the requests involved
- Impact What an attacker could read or change
- Contact How to reach you. A dedicated security address will be published here.
Running a security review?
Talk to us about the authority model, the audit trail and the boundary between ProjectHubs and your agent client.