AIFC-062: Agent Permissions
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-020 Human-Managed AI
- AIFC-021 AI as External Expert Capacity
- AIFC-022 AI-NDA Boundary
- AIFC-023 AI as Team Member
- AIFC-030 AI Capacity Planning
- AIFC-031 AI Autonomy and Intensity
- AIFC-032 AI Operating Modes
- AIFC-033 AI Budget and Cost Control
- AIFC-034 AI Lock-in and Exit Strategy
- AIFC-044 Human Skills and AI Skills
- AIFC-060 Knowledge Security
- AIFC-061 Access Control
Purpose of this document: Define Agent Permissions as a governed permission model for AI agents that work with the knowledge base, tools, Source of Truth, workflows, data, decisions, and community interfaces. Agent Permissions protect the community from AI agents acting outside scope, outside values, outside the AI-NDA Boundary, or outside human responsibility.
1. Purpose of this document
This document defines Agent Permissions.
An AI agent in an AIFC community may be more than a chatbot.
It may:
- read the Source of Truth,
- search the knowledge base,
- summarize,
- classify,
- propose changes,
- create change proposals,
- generate decision support,
- run validators,
- create tasks,
- update metadata,
- write drafts,
- comment on artefacts,
- call external tools,
- work with customer signals,
- support operations,
- analyze security risks,
- help with backlog,
- or act as a governed team member.
Such an agent needs clearly defined permissions.
General access to tools is not enough.
Agent Permissions define:
- what the agent may read,
- what it must not read,
- what it may propose,
- what it may change,
- what it may execute,
- when it needs approval,
- which data it may process,
- which memory it may use,
- which budget it has,
- which scope it has,
- who owns it,
- how it can be stopped,
- how its actions are audited,
- how it is disconnected.
2. Core principle
The core principle of this document is:
An AI agent may act only within explicit permissions, boundaries, ownership and audit.
AIFC states:
No agent without owner.
No action without boundary.
No autonomy without audit.
An agent should not gain power merely because it is useful.
It should gain permission only because it has a clear purpose, scope, boundary, and responsibility.
3. Definition
Agent Permissions are the rules that determine which resources, data, tools, actions, and decision roles an AI agent may use inside a community.
Agent Permissions include:
- agent identity,
- role,
- owner,
- purpose,
- scope,
- allowed inputs,
- forbidden inputs,
- allowed data classifications,
- forbidden data classifications,
- allowed actions,
- forbidden actions,
- tool permissions,
- read permissions,
- write permissions,
- approval boundaries,
- autonomy level,
- operating mode,
- memory rules,
- AI-NDA Boundary,
- budget guardrails,
- audit requirements,
- escalation rules,
- human override,
- revocation,
- exit strategy.
Minimum requirement
Every AI agent with access to non-public know-how, tools, or Source of Truth must have an explicit permissions record.
4. Why Agent Permissions matter
An AI agent may combine three powers:
knowledge access
+
reasoning capability
+
tool action
This combination is powerful.
Without permissions, an agent may:
- read overly sensitive data,
- combine data that should not be combined,
- create sensitive derived knowledge,
- change the Source of Truth outside review,
- run an inappropriate tool,
- contact the wrong actor,
- propose a dangerous change,
- spend budget,
- create AI lock-in,
- write unapproved content,
- bypass human decision-making,
- or expand access beyond original scope.
Agent Permissions are not an obstacle to agents.
They are a condition for safe agent participation.
Minimum requirement
AI agents with tools or non-public data must be governed as operational and security subjects.
5. Agent identity
An AI agent must have an identity.
Identity answers:
- What is the agent called?
- What role does it have?
- Who owns it?
- Why does it exist?
- Where is it recorded?
- Which workflow does it support?
- Which permissions does it have?
- How can its outputs be recognized?
- How can its actions be recognized in an audit log?
An agent without identity is unmanaged automation.
Minimum requirement
An AI agent with meaningful impact must have a unique identity and traceable owner.
6. Agent owner
The agent owner is the person or community role responsible for the agent.
The owner is responsible for:
- agent purpose,
- permissions,
- scope,
- AI skill,
- security boundary,
- review,
- cost guardrails,
- output quality,
- incident response,
- revocation,
- retirement,
- exit strategy.
The owner does not need to personally check every output.
But the owner is responsible for the agent’s operating frame.
Minimum requirement
No meaningful AI agent may operate without an owner.
7. Agent purpose
An agent must have a clear purpose.
Poor example:
General company assistant.
Better example:
Knowledge Maintenance Agent that detects missing owners, outdated artefacts and metadata inconsistencies in the internal AIFC knowledge base and creates draft maintenance proposals.
Purpose limits the agent.
The agent should not do everything it can technically do.
It should do what it was approved to do.
Minimum requirement
Agent permissions must be derived from the agent’s explicit purpose.
8. Agent scope
Scope defines where the agent may operate.
Scope may be:
- a specific knowledge domain,
- a specific project,
- a specific team,
- a specific workflow,
- a specific data classification,
- a specific tool,
- a specific time period,
- a specific mission,
- a specific interface.
Example:
Agent may operate only in /work/maintenance and /feedback/signals.
Agent must not access /strategy/restricted or /operational-dna.
Minimum requirement
An agent with meaningful impact must have defined scope and out-of-scope areas.
9. Allowed inputs
Allowed inputs define which inputs the agent may use.
Examples:
- public documents,
- internal approved artefacts,
- specific backlog items,
- metadata,
- support tickets without personal data,
- approved anonymized customer feedback,
- selected Source of Truth folders.
Allowed inputs must respect classification and the AI-NDA Boundary.
Minimum requirement
Agent permissions must define allowed inputs according to risk.
10. Forbidden inputs
Forbidden inputs define what the agent must not use.
Examples:
- personal data,
- secrets,
- restricted customer data,
- Operational DNA,
- legal privileged content,
- unapproved vendor contracts,
- security incident details,
- credentials,
- private HR data,
- cross-community data without boundary.
Forbidden inputs are as important as allowed inputs.
Minimum requirement
An agent working with non-public know-how must have forbidden inputs defined or inherit prohibitions from classification.
11. Data classification permissions
Agent Permissions must respect data classification.
Example:
Public: allowed
Internal: allowed within scope
Restricted: approval required
Operational DNA: forbidden unless explicitly approved
An agent does not automatically inherit everything its owner can see.
Agent access is a separate permission.
Minimum requirement
Agent permissions must explicitly state which classification levels the agent may process.
12. Allowed actions
Allowed actions define what the agent may do.
Examples:
- read,
- summarize,
- classify,
- detect missing metadata,
- create draft,
- create proposal,
- comment,
- suggest owner,
- run validator,
- create task,
- update draft metadata,
- prepare report,
- escalate signal.
Allowed actions must be specific.
Minimum requirement
Agent permissions must define allowed actions, not only allowed data.
13. Forbidden actions
Forbidden actions define what the agent must not do.
Examples:
- approve decision,
- publish external content,
- delete artefact,
- lower classification,
- change AI-NDA Boundary,
- grant access,
- revoke access,
- change Operational DNA,
- contact customer,
- execute financial transaction,
- modify security rule,
- update active workflow,
- train external model,
- export restricted knowledge.
Minimum requirement
Agent permissions must define forbidden actions for meaningful agents.
14. Read permissions
Read permissions define what the agent may read.
They must be limited by:
- scope,
- purpose,
- classification,
- need-to-know,
- AI-NDA Boundary,
- Community Interface,
- role,
- operating mode.
An agent that reads for summarization does not need access to the whole Source of Truth.
Minimum requirement
Agent read access must be based on least privilege.
15. Write permissions
Write permissions are more sensitive than read permissions.
AIFC recommends these levels:
none
draft_only
proposal_only
metadata_suggestion
low_risk_metadata_update
approved_scope_write
none
The agent may not write.
draft_only
The agent may create drafts.
proposal_only
The agent may create change proposals.
metadata_suggestion
The agent may suggest metadata.
low_risk_metadata_update
The agent may update low-risk metadata inside a pre-approved scope.
approved_scope_write
The agent may write inside a narrowly defined approved scope.
Minimum requirement
An AI agent must not write to the active Source of Truth without explicit write permission and an audit trail.
16. Approval boundary
The approval boundary defines when the agent must request human or community approval.
Approval is especially required for:
- active Source of Truth changes,
- publication,
- classification changes,
- Restricted data use,
- Operational DNA access,
- external communication,
- Decision Record approval,
- access changes,
- security changes,
- cost exception,
- autonomy increase,
- AI-NDA Boundary change.
Minimum requirement
An agent with any autonomous action must have an explicit approval boundary.
17. Autonomy level
Agent permissions must align with autonomy level.
Autonomy may be described as:
0 percent - no autonomous action
25 percent - propose only
50 percent - draft with human approval
75 percent - execute approved low-risk actions
100 percent - operate autonomously within strict pre-approved boundaries
Autonomy level must not be interpreted globally.
It must be related to action and scope.
Minimum requirement
Agent autonomy must be defined for action types, not only for the agent as a whole.
18. Operating mode
Agent permissions may change by AI Operating Mode.
Example:
Conservative Mode:
agent proposes only
Balanced Mode:
agent drafts and suggests metadata
Mission Mode:
agent performs high-volume analysis within approved scope
Emergency AI-Off Mode:
agent is paused or read-only
Minimum requirement
Agent permissions must be compatible with the current AI Operating Mode.
19. Tool permissions
Tool permissions define which tools the agent may use.
Examples:
- file search,
- Source of Truth repository,
- Jira,
- ServiceNow,
- Git,
- email,
- calendar,
- BI,
- CMS,
- deployment tools,
- security scanner,
- customer system,
- web access,
- code execution.
Each tool has its own risks.
Especially sensitive tools can write, communicate externally, change production state, access customer data, execute code, or change permissions.
Minimum requirement
Agent tool access must be explicit, limited, and auditable for meaningful tools.
20. External communication permissions
An agent may sometimes communicate outside the community.
Examples:
- reply to a customer,
- send an email,
- create a public post,
- communicate with a vendor,
- create a ticket in an external system.
External communication is highly sensitive.
It must cover:
- tone,
- approval,
- identity,
- liability,
- AI disclosure,
- privacy,
- customer harm,
- brand,
- legal review.
Minimum requirement
An AI agent must not autonomously communicate externally about meaningful matters without explicit permission and approval rules.
21. Decision permissions
An agent may help with decisions.
It must be clear whether the agent:
- only analyzes,
- proposes,
- recommends,
- prepares a Decision Record,
- or may perform a low-risk delegated decision.
Critical decisions must remain with a responsible person or community role.
Minimum requirement
Agent permissions must distinguish analysis, proposal, recommendation, decision, and approved change.
22. Memory permissions
Agent memory may be useful but risky.
Memory permissions must define:
- whether the agent may store memory,
- which data may be stored,
- for how long,
- who can see it,
- whether it is auditable,
- whether it is exportable,
- whether it can be deleted,
- whether it may contain Restricted data,
- whether it may contain Operational DNA.
Minimum requirement
Agent memory must not contain Restricted knowledge or Operational DNA without explicit permission and boundary.
23. Derived knowledge permissions
An agent may create derived knowledge.
Examples:
- strategy synthesis,
- weakness map,
- customer patterns,
- Operational DNA summary,
- risk profile,
- dependency list.
Derived knowledge may be more sensitive than its inputs.
Minimum requirement
Agent-generated derived knowledge must be classified and protected by impact.
24. Export permissions
Agent export is risky.
An agent may export:
- files,
- reports,
- summaries,
- embeddings,
- logs,
- data extracts,
- Source of Truth slices,
- AI outputs,
- customer patterns.
Export permissions must be explicit.
Minimum requirement
An agent must not export Restricted knowledge or Operational DNA without explicit export permission and audit.
25. Budget permissions
An agent may consume AI budget.
Budget permissions must define:
- max cost per run,
- max cost per day,
- max token usage,
- max steps,
- max retries,
- max documents processed,
- pause threshold,
- approval threshold,
- owner alert threshold.
Minimum requirement
An agent with repeated or autonomous operation must have cost guardrails.
26. Rate and volume limits
An agent may create a large amount of work.
This can cause:
- review overload,
- attention debt,
- governance overload,
- API cost,
- storage cost,
- incident noise.
Rate limits may limit:
- number of proposals,
- number of comments,
- number of tasks,
- number of documents analyzed,
- number of runs per day,
- number of escalations.
Minimum requirement
An agent that generates high output volume must have rate or volume limits.
27. Escalation rules
The agent must know when to escalate.
Escalation is necessary when the agent:
- encounters forbidden input,
- detects a security risk,
- detects a values conflict,
- is unsure about classification,
- needs higher permission,
- exceeds budget,
- detects Operational DNA,
- finds an AI-NDA Boundary issue,
- encounters cross-community impact,
- detects an incident.
Minimum requirement
An agent with meaningful impact must have escalation rules.
28. Human override
Human override allows a person or role to stop or restrict the agent.
It may include:
- pause,
- kill switch,
- revoke access,
- reduce permissions,
- disable tool,
- disable memory,
- force read-only mode,
- switch to Emergency AI-Off Mode.
Minimum requirement
An agent with tool access, write access, or autonomy must have a human override mechanism.
29. Revocation
Agent permissions must be revocable.
Revocation is necessary for:
- incident,
- scope violation,
- owner change,
- project end,
- vendor exit,
- model risk,
- AI-NDA Boundary violation,
- budget issue,
- retirement,
- values conflict.
Revocation must also address:
- agent memory,
- cached data,
- tokens,
- API keys,
- embeddings,
- logs,
- derived knowledge,
- scheduled tasks.
Minimum requirement
An AI agent with non-public access must have a revocation path.
30. Agent onboarding
Agent onboarding is the process of introducing an agent.
It should include:
- purpose,
- owner,
- scope,
- permissions,
- AI skill,
- human skill,
- AI-NDA Boundary,
- access review,
- security review,
- budget guardrails,
- testing,
- audit setup,
- fallback,
- exit strategy.
Minimum requirement
A meaningful AI agent must pass onboarding before production use.
31. Agent offboarding
Agent offboarding is the process of ending an agent.
It must include:
- removing access,
- disabling tools,
- exporting or deleting memory,
- archiving audit logs,
- returning useful know-how to the Source of Truth,
- closing open proposals,
- cancelling scheduled runs,
- reviewing dependencies,
- exit retrospective.
Minimum requirement
A meaningful AI agent must have an offboarding procedure.
32. Agent review
Agent permissions must be reviewed regularly.
Review asks:
- Is the agent still needed?
- Is the purpose current?
- Is the scope correct?
- Does it still have the right owner?
- Are permissions too broad?
- Do guardrails work?
- What is the cost?
- What is the value?
- Is dependency emerging?
- Is lock-in emerging?
- Does the skill need an update?
- Were there incidents?
Minimum requirement
AI agents with non-public access, tool access, or autonomy must have a review cycle.
33. Agent auditability
Audit must show:
- who the agent is,
- what it read,
- what it created,
- what it changed,
- which tool it used,
- which model it used,
- when it acted,
- under which skill,
- with which permissions,
- whether approval was needed,
- who approved,
- what the result was.
Minimum requirement
Autonomous or tool-using agents must be auditable according to risk.
34. Agent permissions and Source of Truth
Agent permissions must be recorded in the Source of Truth or a governance repository.
They must not exist only in:
- vendor UI,
- chat,
- local configuration,
- personal prompt,
- agent memory.
The Source of Truth must hold at least:
- agent identity,
- owner,
- purpose,
- scope,
- permissions,
- review cycle,
- status.
Minimum requirement
Meaningful agent permissions must be traceable outside the runtime AI tool.
35. Agent permissions and skills
Agent permissions must align with the AI skill.
The AI skill says how the agent should work.
Permissions say what the agent may actually do.
If the AI skill says something the permissions do not allow, permissions take precedence.
Minimum requirement
An AI skill must not expand agent permissions without governance approval.
36. Agent permissions and values
Agent permissions must reflect community values.
Examples:
- human responsibility means the agent must not approve critical decisions,
- privacy means the agent must not process personal data without boundary,
- resilience means the agent must not be the only performer of critical routine work without fallback,
- care means the agent should create maintenance proposals, not only delivery outputs,
- transparency means agentic outputs are marked.
Minimum requirement
Agent permissions must align with community values and non-negotiable boundaries.
37. Agent permissions and Human Capability Reserve
An agent with high autonomy may weaken human capability.
Permissions must consider:
- whether people understand the agent’s work,
- whether a human skill exists,
- whether fallback exists,
- whether people can review the output,
- whether the agent replaces a junior learning path,
- whether the agent becomes the only carrier of know-how.
Minimum requirement
A critical agent must have an assessment of impact on Human Capability Reserve.
38. Agent permissions and AI lock-in
An agent may create lock-in if:
- its memory is not exportable,
- its skills are proprietary,
- its workflow is not documented,
- its permissions are not outside the vendor platform,
- its actions are not auditable,
- its outputs are not written back to the Source of Truth,
- people cannot replace it.
Minimum requirement
A critical agent must have an exit strategy or replacement plan.
39. Agent permissions and cross-community work
An agent working across communities has higher risk.
It must have:
- affected communities,
- data sharing boundary,
- multi-community AI-NDA Boundary,
- decision ownership,
- escalation path,
- output sharing rules,
- audit,
- representation of impacted communities if needed.
Minimum requirement
A cross-community agent must have a multi-community boundary and governance owner.
40. Agent incident
An agent incident is a situation where the agent violates or threatens the rules.
Examples:
- it reads forbidden data,
- it uses an unapproved tool,
- it writes outside scope,
- it exports Restricted data,
- it creates sensitive derived knowledge without classification,
- it exceeds budget,
- it acts without approval,
- it publishes inappropriate content,
- it runs an impactful tool,
- it ignores the AI-NDA Boundary.
Minimum requirement
Agent incidents must be recorded, triaged, and handled as knowledge security or AI governance incidents.
41. Suggested metadata
Example metadata for agent permissions:
agent_permissions:
id:
agent_id:
agent_name:
status: draft | proposed | active | paused | revoked | retired | archived
owner:
purpose:
scope:
out_of_scope:
related_ai_skill:
related_human_skill:
related_workflows:
operating_mode:
autonomy_profile:
allowed_inputs:
forbidden_inputs:
allowed_data_classifications:
forbidden_data_classifications:
allowed_actions:
forbidden_actions:
read_permissions:
write_permissions:
level: none | draft_only | proposal_only | metadata_suggestion | low_risk_metadata_update | approved_scope_write
tool_permissions:
external_communication_allowed: true | false
decision_permissions:
analysis: true | false
proposal: true | false
recommendation: true | false
decision: true | false
memory_permissions:
memory_allowed: true | false
restricted_memory_allowed: true | false
operational_dna_memory_allowed: true | false
derived_knowledge_rules:
export_permissions:
budget_guardrails:
rate_limits:
approval_boundary:
escalation_rules:
human_override:
revocation_path:
audit_required: true | false
review_cycle:
last_reviewed:
Example metadata for an agent incident:
agent_incident:
id:
title:
status: observed | triaged | contained | under_review | resolved | closed
agent_id:
owner:
incident_type:
- forbidden_input_access
- out_of_scope_action
- unauthorized_write
- unauthorized_export
- boundary_violation
- budget_exceeded
- approval_bypass
- tool_misuse
- external_communication_issue
- derived_knowledge_misclassification
affected_artefacts:
affected_communities:
severity: low | medium | high | critical
containment_actions:
permissions_revoked: true | false
root_cause:
corrective_actions:
related_change_proposal:
created_at:
closed_at:
These structures are illustrative.
The final schema should be defined in the agent-actionable layer of the standard.
42. Anti-patterns
AIFC rejects the following anti-patterns.
42.1 Agent without owner
An agent runs, but nobody is responsible for it.
42.2 Agent with vague purpose
An agent has an overly general purpose and gradually gains an uncontrolled role.
42.3 Agent with broad access
An agent has access to the whole Source of Truth because it is convenient.
42.4 Agent with write access by default
An agent may write to the Source of Truth without clear rules.
42.5 Agent approves its own proposals
An agent creates a proposal and also marks it approved.
42.6 Agent memory as hidden Source of Truth
Critical know-how is in agent memory, not in the Source of Truth.
42.7 Tool access without action boundary
An agent has a tool, but it is unclear which actions it may perform.
42.8 Agent external communication without approval
An agent communicates externally without rules, tone guidance, legal boundary, or approval.
42.9 Permissions only in vendor UI
Agent permissions exist only in a proprietary platform and are not auditable in the Source of Truth.
42.10 No kill switch
The agent cannot be stopped quickly.
42.11 Agent ignores operating mode
The agent continues autonomous actions after the community switches to Reduced-AI or Emergency AI-Off Mode.
42.12 Agent replaces human capability
The agent becomes the only performer of critical work without human skill and fallback.
43. Minimal requirements
An AIFC community must at minimum meet these Agent Permissions requirements:
- An AI agent with non-public know-how, tools, or Source of Truth has a permissions record.
- AI agents with tools or non-public data are governed as operational and security subjects.
- A meaningful AI agent has identity.
- A meaningful AI agent has an owner.
- Agent permissions are derived from the agent’s explicit purpose.
- An agent with meaningful impact has scope and out-of-scope areas.
- Agent permissions define allowed inputs.
- Agent permissions define forbidden inputs or inherit them from classification.
- Agent permissions define allowed classification levels.
- Agent permissions define allowed actions.
- Agent permissions define forbidden actions for meaningful agents.
- Agent read access is based on least privilege.
- An agent must not write to the active Source of Truth without write permission and audit.
- An agent with autonomous action has an approval boundary.
- Agent autonomy is defined for action types.
- Agent permissions are compatible with AI Operating Mode.
- Agent tool access is explicit, limited, and auditable.
- An agent must not autonomously communicate externally about meaningful matters without permission and approval rules.
- Agent permissions distinguish analysis, proposal, recommendation, decision, and approved change.
- Agent memory must not contain Restricted knowledge or Operational DNA without permission and boundary.
- Agent-generated derived knowledge is classified by impact.
- An agent must not export Restricted knowledge or Operational DNA without permission and audit.
- An agent with repeated or autonomous operation has cost guardrails.
- An agent generating high output volume has rate or volume limits.
- An agent with meaningful impact has escalation rules.
- An agent with tool access, write access, or autonomy has human override.
- An agent with non-public access has a revocation path.
- A meaningful agent passes onboarding before production use.
- A meaningful agent has an offboarding procedure.
- An agent with non-public access, tool access, or autonomy has a review cycle.
- Autonomous or tool-using agents are auditable according to risk.
- Meaningful agent permissions are traceable outside the runtime AI tool.
- An AI skill must not expand agent permissions without governance approval.
- Agent permissions align with values and non-negotiable boundaries.
- A critical agent has an assessment of impact on Human Capability Reserve.
- A critical agent has an exit strategy or replacement plan.
- A cross-community agent has a multi-community boundary and governance owner.
- Agent incidents are handled as knowledge security or AI governance incidents.
44. Summary
Agent Permissions protect the community from allowing a useful AI agent to become an unmanaged actor.
An agent can be powerful because it combines knowledge access, reasoning capability, and tool action.
AIFC therefore states:
Define the agent.
Own the agent.
Limit the agent.
Audit the agent.
Stop the agent when needed.
An AI agent should be a governed member of the system, not a hidden operational subject without responsibility.
Agent Permissions turn AI agents into bounded, auditable and governed actors.