AIFC-061: Access Control

Status: Draft 0.1 Standard: AI-First Community Standard Short name: AIFC Builds on:

• AIFC-000 Manifesto for AI-First Communities
• AIFC-001 Core Concepts
• AIFC-010 Knowledge Structure
• AIFC-011 Operational DNA
• AIFC-012 Metadata and Markdown
• AIFC-020 Human-Managed AI
• AIFC-022 AI-NDA Boundary
• AIFC-023 AI as Team Member
• AIFC-034 AI Lock-in and Exit Strategy
• AIFC-050 Community Interface
• AIFC-060 Knowledge Security

Purpose of this document: Define Access Control as a governed mechanism for access by people, AI agents, systems, vendors, and communities to the knowledge base, Source of Truth, Operational DNA, skills, decisions, workflows, and interfaces. Access Control protects not only data, but community capability, responsibility, integrity, and trust.

1. Purpose of this document

This document defines Access Control.

An AIFC community works with knowledge that may be public, internal, sensitive, or critical.

Access Control states:

• who may read,
• who may change,
• who may approve,
• who may export,
• who may share,
• who may involve AI,
• who may give access to a vendor,
• who may work with Operational DNA,
• who may change classification,
• who may change the AI-NDA Boundary,
• who may change agent permissions,
• who may publish an output externally.

In AIFC, Access Control is not only a technical permission setting.

It is a governance mechanism that protects know-how ownership, trust, responsibility, and community capability.

2. Core principle

The core principle of this document is:

Access to knowledge is access to community capability.

AIFC states:

Grant access by purpose, role, sensitivity and responsibility, not by convenience.

Access Control should not block work unnecessarily.

It should ensure that community capability is shared correctly, safely, and responsibly.

3. Definition

Access Control is the set of rules, roles, permissions, approvals, audits, and revocation mechanisms that determine who or what may access knowledge artefacts and which actions they may perform.

Access Control applies to:

• people,
• AI agents,
• AI tools,
• systems,
• integrations,
• vendors,
• external experts,
• service accounts,
• partner communities,
• the public,
• the Human Cockpit Layer,
• retrieval systems,
• vector stores,
• exports.

Access Control defines access not only to data, but also to actions.

Minimum requirement

Every meaningful knowledge artefact or knowledge system must have governed access appropriate to its classification and impact.

4. Why Access Control matters

Without governed access, the community faces risks such as:

• know-how leakage,
• Operational DNA leakage,
• unauthorized AI processing,
• unauthorized Source of Truth changes,
• unclear approval,
• irreversible exports,
• vendor lock-in,
• agentic actions outside scope,
• silent rewriting of decisions,
• misuse of sensitive metadata,
• loss of trust,
• inability to audit,
• loss of ability to govern the community.

Access Control is not only protection against an attacker.

It also protects against accidental sharing, unclear ownership, tools without boundaries, and AI agents without responsibility.

Minimum requirement

An AIFC community must understand Access Control as protection of knowledge and operational capability, not only as an IT permission model.

5. Access is action-specific

Access is not a single value.

It is not enough to say:

User has access.

The type of access must be defined.

Possible actions:

read
comment
propose
edit draft
approve
publish
export
share
classify
declassify
delete
archive
restore
grant access
revoke access
process with AI
write back from AI
run agent
modify agent permissions

Someone may be allowed to read but not export. Someone may be allowed to propose a change but not approve it. AI may be allowed to summarize public content but not write to the Source of Truth.

Minimum requirement

Critical artefacts must distinguish at least read, write, approve, export, and AI processing permissions.

6. Role-based access

Role-based access assigns permissions by role.

Example roles:

• community owner,
• knowledge owner,
• artefact owner,
• contributor,
• reviewer,
• approver,
• security owner,
• AI governance owner,
• AI team member owner,
• external expert,
• vendor,
• auditor,
• public reader.

Role-based access is an important foundation.

It is not sufficient on its own.

It must be complemented by purpose limitation, classification, and context.

Minimum requirement

An AIFC community must define roles for access to critical knowledge artefacts.

7. Purpose-based access

Purpose-based access means that access is justified only for a specific purpose.

Example:

Vendor may access restricted workflow documentation only for migration assessment, not for training its own AI models or reuse with other customers.

Purpose limits:

• what may be read,
• what may be processed with AI,
• whether export is allowed,
• whether copies may be stored,
• whether derived knowledge may be created,
• how long access lasts.

Minimum requirement

Restricted knowledge and Operational DNA must use purpose limitation.

8. Least privilege

Least privilege means that a subject has only the access it needs.

This applies to:

• people,
• AI agents,
• vendors,
• integrations,
• service accounts,
• retrieval systems.

Examples:

• a maintenance agent does not need access to finance strategy,
• a UX agent does not need customer personal data,
• a vendor does not need the whole Source of Truth,
• an AI summarizer does not need write access.

Minimum requirement

Access to Restricted knowledge and Operational DNA must be based on least privilege.

9. Need-to-know

Need-to-know means that a member or system has access only when it truly needs it for a task.

It is not enough to say:

They are a company member.

The question is:

Do they need this specific artefact for this specific purpose?

Minimum requirement

Operational DNA must be accessible only to subjects with clear need-to-know.

10. Access by classification

Access Control must respect classification.

Recommended layers:

Public
Internal
Restricted
Operational DNA

Public

May be read publicly.

Internal

Reading is limited to the community or organization.

Restricted

Access is limited by role, purpose, and approval.

Operational DNA

Access is highly limited, audited, and approved.

Minimum requirement

Access rules must be defined for each classification level.

11. Public access

Public access means that an artefact may be seen by the public.

Even a public artefact must be governed.

Risks:

• a public interface may reveal Operational DNA,
• metadata may reveal internal structure,
• AI-generated public text may be unapproved,
• a public document may be outdated,
• a public API may reveal more than intended.

Minimum requirement

Public artefacts must have an owner, status, and review against sensitive leakage when they are derived from the internal knowledge base.

12. Internal access

Internal access means access inside the community or organization.

Internal does not automatically mean safe.

Risks:

• overly broad internal access,
• AI tools available to everyone,
• copying sensitive parts into chats,
• uncontrolled sharing with externals,
• weak offboarding.

Minimum requirement

Internal knowledge must have rules for AI use, external sharing, and offboarding.

13. Restricted access

Restricted access applies to sensitive knowledge.

It may include:

• customer information,
• security rules,
• internal strategy,
• vendor contracts,
• financial plans,
• incident records,
• restricted workflows,
• restricted AI skills,
• legal or compliance artefacts.

Restricted access requires:

• owner,
• approval,
• need-to-know,
• audit,
• retention,
• AI-NDA Boundary.

Minimum requirement

Restricted artefacts must have an owner, approval rules, and audit or access logging appropriate to the risk.

14. Operational DNA access

Operational DNA access is the most sensitive access.

It may allow a subject to understand or replicate community capability.

Operational DNA access must be:

• explicitly approved,
• purpose-limited,
• time-bound,
• audited,
• minimal,
• revocable,
• protected against export,
• protected against uncontrolled AI processing,
• regularly reviewed.

Minimum requirement

Operational DNA access must have explicit approval, owner, audit, purpose limitation, and a revocation path.

15. Human access

Human access is access by people.

It must cover:

• employees,
• community members,
• externals,
• vendors,
• consultants,
• auditors,
• leadership,
• temporary roles,
• emergency access.

Human access must be connected to:

• role,
• purpose,
• duration,
• training,
• NDA or AI-NDA-like boundaries,
• offboarding,
• access review.

Minimum requirement

Human access to critical artefacts must be regularly reviewed.

16. AI access

AI access is access by an AI tool, model, agent, or workflow to knowledge artefacts.

AI access must define:

• allowed tools,
• allowed models,
• allowed artefacts,
• forbidden artefacts,
• memory rules,
• training rules,
• derived knowledge rules,
• prompt/output visibility,
• write-back permissions,
• audit,
• owner,
• revocation.

AI access is not the same as human access.

The fact that a person may read a document does not mean they may place it in any AI tool.

Minimum requirement

AI access must be explicitly allowed for non-public knowledge artefacts.

17. Agent access

Agent access is a special case of AI access.

An agent may not only read, but also act.

It must therefore have:

• identity,
• role,
• owner,
• scope,
• allowed actions,
• forbidden actions,
• tool access,
• data access,
• write access,
• approval boundary,
• cost guardrails,
• audit,
• kill switch,
• exit strategy.

Minimum requirement

An AI agent with write access or tool access must have an explicit permissions record.

18. System access

System access includes applications, integrations, APIs, retrieval systems, CI/CD, analyzers, validators, and other technical services.

Risk appears when a system:

• reads more than it needs,
• writes without review,
• exports data,
• logs sensitive content,
• creates embeddings,
• shares data with AI,
• has long-lived credentials.

Minimum requirement

System access to a critical knowledge base must be governed, auditable, and revocable.

19. Vendor access

Vendor access must be specially governed.

A vendor may need access for:

• implementation,
• support,
• migration,
• audit,
• consulting,
• AI setup,
• system integration.

Vendor access must have:

• purpose,
• scope,
• data boundary,
• AI use rules,
• retention rules,
• export rules,
• knowledge return obligation,
• audit,
• expiry,
• revocation,
• exit strategy.

Minimum requirement

Vendor access to Restricted knowledge or Operational DNA must have explicit ownership, time limitation, and boundary.

20. Cross-community access

Cross-community access occurs when one community gives access to another community.

This may involve:

• partner,
• customer,
• vendor,
• regulator,
• open community,
• joint venture,
• federated governance.

The access must define:

• what is shared,
• for what purpose,
• who is responsible,
• what classification applies,
• whether AI processing is allowed,
• how derived knowledge is handled,
• how access ends.

Minimum requirement

Cross-community access to non-public know-how must have a data sharing boundary and owner.

21. Access request

An access request is the process by which a subject asks for access.

The request should include:

• who requests access,
• why access is needed,
• which artefacts are requested,
• which action is needed,
• for how long,
• whether AI will be used,
• whether export will occur,
• whether derived knowledge will be created,
• what the classification is,
• who approves.

Minimum requirement

Access to Restricted knowledge and Operational DNA must be granted through an approved access request or equivalent process.

22. Access approval

Access approval must be appropriate to risk.

Possible approvers:

• artefact owner,
• knowledge owner,
• security owner,
• AI governance owner,
• community owner,
• legal/compliance owner,
• Operational DNA owner.

Approval must be stronger for:

• Operational DNA,
• AI processing,
• export,
• vendor access,
• cross-community access,
• public release,
• write permissions,
• declassification.

Minimum requirement

Critical access must be approved by a responsible role according to classification and action type.

23. Time-bound access

Access should not be permanent unless necessary.

Time-bound access is appropriate for:

• vendors,
• consultants,
• audit,
• mission mode,
• migration,
• incident response,
• temporary project teams,
• AI experiments.

Minimum requirement

Temporary or external access to critical artefacts must have an expiration or review date.

24. Emergency access

Emergency access may be necessary during an incident.

It must be:

• limited,
• audited,
• justified,
• time-bound,
• reviewed afterward.

Emergency access must not become a permanent back door.

Minimum requirement

Emergency access to critical knowledge must be logged and later reviewed.

25. Access revocation

Access revocation is the ability to remove access.

Revocation must cover:

• people,
• vendors,
• AI agents,
• integrations,
• API keys,
• service accounts,
• retrieval systems,
• vector stores,
• exported copies,
• agent memory,
• cached content.

Revocation must be available for:

• offboarding,
• role change,
• incident,
• boundary violation,
• vendor exit,
• project end,
• AI tool deprecation.

Minimum requirement

Every critical access path must have a revocation path.

26. Offboarding

Offboarding is a special case of revocation.

It must ensure:

• removal of access,
• know-how handover,
• credential cancellation,
• AI tool access removal,
• agent permission removal,
• export review,
• local copy review,
• Source of Truth preservation,
• audit.

Minimum requirement

Departure of a person, vendor, or agent with access to critical know-how must trigger an offboarding checklist.

27. Access review

Access review regularly checks whether access still makes sense.

Questions:

• Who has access?
• Why?
• Is it still needed?
• Is the scope correct?
• Is AI access still allowed?
• Is access too broad?
• Are there orphaned accounts?
• Are there agents without owners?
• Are vendor permissions still active after the project ended?

Minimum requirement

Restricted knowledge and Operational DNA must have regular access review.

28. Access audit

Audit must make it possible to know:

• who read,
• who changed,
• who approved,
• who exported,
• who shared,
• who used AI,
• which agent acted,
• with which tool,
• when,
• for what purpose,
• and with what result.

Audit does not need the same level of detail for everything.

It must match the risk.

Minimum requirement

Critical actions on Restricted knowledge or Operational DNA must be auditable.

29. Export permissions

Export is a high-risk action.

Export may bypass ordinary access control.

Export permissions must define:

• who may export,
• what scope,
• for what purpose,
• in what format,
• to where,
• whether export can be sent to AI,
• whether it contains metadata,
• whether it contains Operational DNA,
• whether it is audited,
• whether it is encrypted,
• whether it has retention.

Minimum requirement

Export of Restricted knowledge or Operational DNA must require explicit permission and audit.

30. Sharing permissions

Sharing permissions govern sharing with other people, teams, communities, or systems.

Sharing is not the same as reading.

A person may be allowed to read a document but not share it onward.

AI may be allowed to process an internal document but not send the output to an external vendor.

Minimum requirement

Restricted knowledge must distinguish read access from share access.

31. Write permissions

Write permissions define who may change the Source of Truth.

They must distinguish:

• edit draft,
• propose change,
• update active content,
• approve change,
• publish,
• deprecate,
• archive,
• delete.

AI write access is especially sensitive.

Minimum requirement

Critical Source of Truth artefacts must distinguish propose, edit, approve, and publish permissions.

32. Approval permissions

Approval is a higher permission than editing.

Approval may change the status of knowledge into an active rule.

Risks:

• approving AI output without review,
• approving one’s own proposal without independent control,
• approving changes to values, AI-NDA Boundary, or Operational DNA rules without governance,
• automatic approvals without an owner.

Minimum requirement

Critical approval must be separated from ordinary editing and must have a responsible owner.

33. Classification permissions

Changing classification is a sensitive action.

Declassification may expose know-how.

Reclassification may block work.

AI may propose classification, but should not lower the sensitivity of a critical artefact by itself.

Minimum requirement

Lowering the classification of a Restricted or Operational DNA artefact must require approval.

34. AI processing permission

AI processing permission states whether an artefact may be placed into AI, processed by an agent, or used in retrieval.

It must distinguish:

• AI allowed,
• AI allowed with approved tools only,
• AI allowed only with redaction,
• AI allowed only in private environment,
• AI forbidden,
• AI requires owner approval,
• AI requires AI-NDA Boundary.

Minimum requirement

Every Restricted or Operational DNA artefact must have a clear AI processing rule or inherit it from classification.

35. Human Cockpit Layer access

The Human Cockpit Layer may aggregate access to many artefacts.

It must respect:

• user role,
• artefact classification,
• AI access,
• interface scope,
• aggregation risk,
• derived knowledge,
• metadata visibility,
• decision rights.

The cockpit must not show a user a synthesis from data they should not be able to access individually.

Minimum requirement

The Human Cockpit Layer must respect the same or stricter access rules than the Source of Truth.

36. Retrieval access

AI retrieval may compose an answer from many documents.

Retrieval access must ensure:

• the user has the right to all sources used,
• the agent has the right to all sources used,
• the answer does not reveal Restricted content,
• metadata is not leaked,
• embeddings are isolated correctly,
• results are filtered by permission.

Minimum requirement

AI retrieval must not bypass access control through aggregated answers.

37. Access to metadata

Metadata may be sensitive.

Metadata access must cover:

• owner,
• status,
• priority,
• classification,
• risk level,
• AI access,
• related artefacts,
• decision state,
• Operational DNA mapping.

Sometimes metadata must be protected like content.

Minimum requirement

Metadata access must be governed for Restricted and Operational DNA artefacts.

38. Access and Source of Truth write-back

If AI or a human creates an output that should be written back to the Source of Truth, it must have write-back permission.

Write-back must define:

• who writes,
• whether the output is a draft,
• whether it is a proposal,
• whether review is needed,
• who approves,
• how AI-generated content is marked,
• how lineage is stored.

Minimum requirement

AI write-back to the Source of Truth must be limited, audited, and usually start as a draft or proposal.

39. Access and separation of duties

Some actions must be separated.

Examples:

• the proposal author is not the approver,
• an AI agent does not both propose and approve the same change,
• a vendor cannot approve its own output,
• the person lowering classification is not the only reviewer,
• an agent that creates a change proposal cannot mark it as accepted.

Minimum requirement

Critical decisions and changes must use separation of duties appropriate to risk.

40. Access and values

Access Control must align with values.

Examples:

• trust requires transparent access,
• security requires limited access,
• learning requires access to harmless examples,
• resilience requires know-how not to be trapped with one person,
• privacy requires minimization.

Overly strict access control can kill learning. Overly loose access control can destroy trust.

Minimum requirement

Access rules must balance security, learning, responsibility, and operational need.

41. Access and Human Capability Reserve

Access Control must not unintentionally destroy Human Capability Reserve.

If only an AI agent or a narrow group can see critical know-how, the community loses recovery capability.

The community must ensure:

• appropriate human know-how,
• backup roles,
• fallback access,
• training access to safe versions,
• redacted learning examples,
• emergency access.

Minimum requirement

Critical know-how must be available to enough responsible people for the community to preserve recovery capability.

42. Access and AI lock-in

Access Control must protect against AI lock-in.

Risk appears when:

• an AI vendor holds knowledge,
• agent memory contains critical context,
• skills are in a proprietary platform,
• export is unavailable,
• access logs are unavailable,
• a vendor can restrict access to the community’s own knowledge.

Minimum requirement

Access to critical knowledge through AI vendor systems must support exit strategy and exportability.

43. Access incident

An access incident is a situation where access violates rules.

Examples:

• an unauthorized user gains access,
• an AI tool processes Restricted data without boundary,
• a vendor downloads more data than approved,
• an agent performs a forbidden action,
• an export contains Operational DNA,
• metadata leaks through a dashboard,
• a retrieval answer reveals Restricted content.

Minimum requirement

Access incidents must be recorded, triaged, and handled as knowledge security incidents.

44. Suggested metadata

Example metadata for access policy:

access_policy:
  id:
  title:
  status: draft | active | under_review | deprecated | archived
  owner:
  scope:
  applies_to_classification:
    - public
    - internal
    - restricted
    - operational_dna
  human_access:
    allowed_roles:
    approval_required: true | false
    review_cycle:
  ai_access:
    allowed: true | false
    allowed_tools:
    allowed_models:
    ai_nda_boundary:
    memory_allowed: true | false
    training_allowed: true | false
  actions:
    read:
    comment:
    propose:
    edit:
    approve:
    publish:
    export:
    share:
    delete:
    classify:
    declassify:
    process_with_ai:
    write_back_from_ai:
  audit_required: true | false
  revocation_required: true | false
  emergency_access_allowed: true | false
  last_reviewed:

Example metadata for access request:

access_request:
  id:
  title:
  status: requested | under_review | approved | rejected | expired | revoked
  requester:
  requester_type: human | ai_agent | system | vendor | community
  requested_access_to:
  requested_actions:
  purpose:
  classification:
  ai_processing_requested: true | false
  export_requested: true | false
  duration:
  approver:
  approval_reason:
  conditions:
  expires_at:
  audit_required: true | false

Example metadata for agent permissions:

agent_permissions:
  agent_id:
  owner:
  scope:
  allowed_artefacts:
  forbidden_artefacts:
  allowed_actions:
  forbidden_actions:
  write_access: none | draft_only | proposal_only | approved_scope
  export_allowed: true | false
  memory_allowed: true | false
  tools_allowed:
  approval_boundary:
  audit_required: true
  kill_switch:
  review_cycle:

These structures are illustrative.

The final schema should be defined in the agent-actionable layer of the standard.

45. Anti-patterns

AIFC rejects the following anti-patterns.

45.1 Everyone can read everything

Internal openness without classification exposes Restricted knowledge and Operational DNA.

45.2 Human access implies AI access

A person may read a document and therefore places it into any AI tool.

45.3 Agent with admin access

An AI agent has overly broad permissions because it is convenient.

45.4 Vendor access without expiry

A vendor has access long after the project ends.

45.5 Export without governance

Someone exports the knowledge base without approval and audit.

45.6 Draft write equals approved change

The ability to edit a draft is confused with the right to change the active Source of Truth.

45.7 AI declassifies knowledge

AI lowers the sensitivity of an artefact without review.

45.8 Retrieval bypass

An AI answer reveals content the user should not have access to.

45.9 No revocation path

Access cannot be quickly removed during an incident.

45.10 Access only by tool permissions

The community relies only on technical tool permissions and does not govern purpose, AI boundary, export, or derived knowledge.

45.11 Over-restriction kills learning

Everything is so locked down that the community loses learning and onboarding capability.

45.12 Single human bottleneck

Critical know-how is accessible to only one person, so the community has no recovery capability.

46. Minimal requirements

An AIFC community must at minimum meet these Access Control requirements:

1. Meaningful knowledge artefacts have governed access according to classification and impact.
2. Access Control is understood as protection of community capability, not only as an IT permission model.
3. Critical artefacts distinguish read, write, approve, export, and AI processing permissions.
4. The community defines roles for access to critical artefacts.
5. Restricted knowledge and Operational DNA use purpose limitation.
6. Access to Restricted knowledge and Operational DNA is based on least privilege.
7. Operational DNA is accessible only with clear need-to-know.
8. Access rules are defined for classification levels.
9. Public artefacts have owner, status, and sensitive leakage review when derived from the internal knowledge base.
10. Internal knowledge has rules for AI use, external sharing, and offboarding.
11. Restricted artefacts have owner, approval rules, and audit or access log.
12. Operational DNA access has explicit approval, owner, audit, purpose limitation, and revocation path.
13. Human access to critical artefacts is regularly reviewed.
14. AI access is explicitly allowed for non-public knowledge artefacts.
15. An AI agent with write access or tool access has a permissions record.
16. System access to the critical knowledge base is governed, auditable, and revocable.
17. Vendor access to Restricted knowledge or Operational DNA has ownership, time limitation, and boundary.
18. Cross-community access to non-public know-how has a data sharing boundary and owner.
19. Access to Restricted knowledge and Operational DNA is granted through an approved access request or equivalent process.
20. Critical access is approved by a responsible role according to classification and action.
21. Temporary or external access to critical artefacts has expiration or review date.
22. Emergency access is logged and later reviewed.
23. Every critical access path has a revocation path.
24. Offboarding of a person, vendor, or agent triggers a checklist.
25. Restricted knowledge and Operational DNA have regular access review.
26. Critical actions on Restricted knowledge or Operational DNA are auditable.
27. Export of Restricted knowledge or Operational DNA requires permission and audit.
28. Restricted knowledge distinguishes read access from share access.
29. Critical Source of Truth artefacts distinguish propose, edit, approve, and publish permissions.
30. Critical approval is separated from ordinary editing.
31. Lowering classification of a Restricted or Operational DNA artefact requires approval.
32. Restricted or Operational DNA artefacts have AI processing rules or inherit them from classification.
33. The Human Cockpit Layer respects the same or stricter access rules than the Source of Truth.
34. AI retrieval does not bypass access control through aggregated answers.
35. Metadata access is governed for Restricted and Operational DNA artefacts.
36. AI write-back to the Source of Truth is limited, audited, and usually starts as draft or proposal.
37. Critical decisions and changes use separation of duties appropriate to risk.
38. Access rules balance security, learning, responsibility, and operational need.
39. Critical know-how is available to enough responsible people for recovery.
40. Access through AI vendor systems supports exit strategy and exportability.
41. Access incidents are handled as knowledge security incidents.

47. Summary

Access Control in AIFC is not only the question of who can open a file.

It is the question of who has access to community capability.

Who may read its purpose. Who may change its decisions. Who may use its know-how in AI. Who may export its Operational DNA. Who may approve a change. Who may give access to an agent. Who may decide that something is no longer sensitive.

AIFC therefore states:

Control access to knowledge.
Control access to actions.
Control access to AI processing.
Control access to community capability.

Well-designed Access Control enables collaboration without chaos, AI acceleration without uncontrolled leakage, and knowledge sharing without loss of ownership.

Access Control turns knowledge access into governed community trust.